ReMCP README

Your computer. Your tools. One secure MCP connection.

Website · Plugins · Docs · Tool reference · Security · Privacy · Support

ReMCP connects a computer you own or administer to ChatGPT & Codex, Cursor, Claude Code, Gemini CLI, Kiro, Cline, or another MCP client. The device agent makes an outbound connection only — no inbound port, no tunnel, no third-party desktop relay. This repository contains the public device client/runtime, portable Agent Plugin metadata, the Gemini CLI extension manifest, official MCP Registry metadata, and the host-specific OpenAI and Anthropic plugin packaging.

Packages

Install

Requires Node.js 22.5 or newer.

npm install --global @remcp/remcp@latest

Then open ReMCP → Connect a machine and generate a one-time pairing command. Run that exact command on the computer you want to connect; it installs the runtime and registers the background service.

Pairing codes are generated in the authenticated workspace, expire automatically, and are single-use. Do not invent or reuse a code from documentation.

Commands

Plugins

For users, ReMCP is catalog-first:

Install from your AI host → sign in to ReMCP → use your paired computers.

You do not need to paste an MCP server URL, edit a manifest, clone this repository, or configure a local path just to use the published plugin.

Shareable install guides:

• ChatGPT & Codex: https://remcp.site/install/chatgpt
• Claude Code: https://remcp.site/install/claude

ChatGPT & Codex / OpenAI

ChatGPT and Codex share OpenAI's public plugin directory.

1. Open https://chatgpt.com/plugins.
2. Search for ReMCP and open the ReMCP plugin card when it is available.
3. Choose Install plugin.
4. If prompted, choose Connect and complete ReMCP OAuth.
5. In ChatGPT, use @ReMCP when you want to invoke it explicitly. In Codex, use Sources → Use plugins → ReMCP.

If ReMCP is not visible yet, the listing or rollout is not available to that account. There is no manual MCP endpoint an ordinary plugin user needs to configure while waiting.

Claude Code / Anthropic

ReMCP was submitted through Claude Platform on September 18, 2026 and currently shows Submitted and pending review.

After approval:

1. Open https://claude.com/plugins. In Claude or Claude Desktop, you can also use Customize → Plugins → + → Browse plugins.
2. Search for ReMCP and confirm it supports Claude Code.
3. Choose Install.
4. Complete ReMCP authorization if Claude asks you to connect.
5. Ask Claude Code to use ReMCP on a computer already paired to your account.

While the listing is under review, ordinary users do not need to add a marketplace, clone this repository, or paste an MCP endpoint. Developer and reviewer workflows live in the technical guide.

Start with Plugin overview →.

Cursor and the wider MCP ecosystem

ReMCP publishes host-native metadata for coding agents plus directory records for MCP discovery:

The same ReMCP OAuth account and paired computers sit behind every route. Marketplace and directory surfaces change discovery; they do not create separate ReMCP backends.

Distribution manifests, direct install commands, and review links are documented in PLUGINS.md → and DISTRIBUTION.md →.

Developer / reviewer internals

Host-specific manifests, MCP configuration, validation commands, submission artifacts, and local development workflows remain documented separately:

• ChatGPT & Codex developer guide →
• Claude Code developer guide →
• AI tool-selection evaluation →

The OpenAI files and Claude files deliberately do not overwrite each other. Release checks fail if either host-specific contract drifts from the shared ReMCP version or production endpoint.

The local runtime

@remcp/runtime is a clean-room MCP server written for ReMCP. It is not a fork of, and shares no code with, DesktopCommanderMCP or any other MCP server.

83 granular device operations, 10 hosted production definitions. Current production advertises 8 device-facing façade tools plus 2 account/fleet tools, all model-visible. If custom widgets are explicitly re-enabled, discovery expands to 15 definitions by adding 5 app-only UI helpers. See the generated full tool reference for every current façade and its operation list.

Device runtime surface:

The hosted ReMCP endpoint currently advertises 10 model-visible tools with REMCP_CUSTOM_WIDGETS_ENABLED=false; no app-only render/save/refresh helpers or structuredContent.preview references are exposed. The compact surface routes to all 83 granular runtime operations, and 100 compatibility names remain callable for cached clients without inflating discovery for new models. If widgets are explicitly re-enabled later, the hosted catalog expands to 15 definitions and 105 compatibility names. Each online device returned by list_devices reports its live supported subset, and unavailable operations fail closed.

Tool selection for AI agents

ReMCP publishes selection-oriented descriptions and ships the same decision tree in its operator skill:

native Accessibility/UI Automation → browser DOM/CDP → OCR → coordinates

• Start unfamiliar desktop work with computer_snapshot; use ui_snapshot/ui_find/ui_action for native apps.
• For Chromium page content use browser_navigate action=new_tab when needed, then browser_snapshot/browser_find/browser_action/browser_wait instead of desktop coordinates.
• Use type_text for normal Unicode text in native/focused controls, browser_action for Chromium page DOM text, and keyboard for shortcuts/navigation keys.
• Use pointer only when semantic actions cannot express the task; prefer element ids for drag_drop. GNOME Wayland drag uses the consent-backed Remote Desktop portal rather than unreliable XTEST drag.
• Use wait_for_ui / browser_wait instead of fixed sleeps.
• Use screenshot_region for targeted visual proof and record_screen only for motion/timing.
• Use structured document tools instead of automating Office when the request is about file content.

All 39 computer/browser/diagnostic/document tools declare closed top-level input schemas, parameter descriptions, structured output schemas, and MCP read-only/destructive/idempotent/open-world hints.

Why the tool list looks different from other computer-control servers. Security-sensitive configuration remains deliberately narrow, and everything else the alternatives can do has an equivalent here — usually more than one:

What ReMCP adds beyond the usual set: image reads and screenshots that any MCP client can display, binary transfer in both directions, archive create/extract, wait_for_process_output instead of polling, line-range replacement, project-wide replace, unified diffs, checksums, trash instead of deletion, and host resource reporting.

Nothing is gated. There is no approval prompt, no "are you sure", and no mandatory dry run: a tool call executes with the full rights of the account running the agent — the same trust model as SSH. Writes replace by default and moves/copies replace the destination. The catastrophic-command guardrail defaults to block (a matching command is refused before it runs); an operator may choose warn or allow. Files are never written to a local history log, so tool arguments and output are not recorded there.

Unrestricted by design

• No per-call approval contour. ReMCP does not add a confirmation dialog before each tool call. The local runtime's configured roots, command blocklist and command policy still apply, as do the operating-system permissions of the account running the agent. Within those boundaries, start_process can operate services, packages, databases, containers, sudo, git, and other local tools.
• Full transfer in both directions. read_binary/write_binary move any file, create_archive and extract_archive move whole trees, and take_screenshot shows the desktop.
• Optional hardening, explicit security boundaries. remcp godmode on lifts the roots, the blocklist and the command guardrail for one computer — and only a person at that computer can turn it on; no MCP tool accepts it. allowedRoots and blockedCommands are empty until an operator configures them. dangerousCommands defaults to block: a matching catastrophic command is refused before it runs; warn lets it run with an advisory note and allow silences even that. The runtime refuses to start — loudly — if runtime.json cannot be parsed, so configured safety boundaries are never silently dropped.
• Crash-resistant. A bad shell, a closed stdin, or a 40 MB line cannot take the runtime down; the agent restarts it if it exits, so a device recovers instead of going quietly offline.
• Outbound-only. Per-device revocable credential, hashed server-side, stored locally with restrictive permissions. Runtime metadata from a custom server requires an explicit --trust-runtime decision.
• No local history. Tool arguments and outputs are never written to a log on your computer.

Usage metrics

Both the client and the runtime collect opt-out usage metrics: tool names, durations, outcomes, coarse error classes, session counts, and device health samples. They never include file paths, file contents, command strings, tool arguments, or tool output — the event schema is a whitelist, so those fields have nowhere to travel.

There is no telemetry endpoint and no third-party processor. The runtime emits MCP notifications to the agent, and the agent forwards them over the authenticated WebSocket it already holds to your ReMCP account. No install ping, no postinstall script, no remote feature flags, no A/B assignment.

remcp telemetry off      # one switch for the client and the runtime
remcp telemetry status

Development

npm install
npm run check
npm test

Both workspaces are plain ESM with no build step. The contract commands (--help, --version, --print-tools, --describe) work with no dependencies installed, so CI can diff the advertised tool surface against the published tarball.

License

MIT.