REMOTE ARC BLOG
How Remote Arc works: Worker, Durable Objects, OAuth and the local agent
From the outside Remote Arc looks simple: connect an AI client, pair a computer, ask the AI to do something. Internally that request crosses several boundaries, and every boundary exists for a reason.
Step 1: the AI client sees a Remote MCP server.
ChatGPT, Claude or another compatible client connects to a single Remote Arc MCP URL. Tool discovery describes device discovery, file inspection, process inspection, file editing, managed processes, terminal execution and undo.
Step 2: OAuth answers who the AI is acting for.
OAuth establishes user identity, scopes and the client grant. Access tokens can be short-lived, refresh tokens can rotate, and a grant can be revoked without changing the paired-device credential.
Step 3: the Cloudflare Worker is the control-plane entry point.
The Worker handles MCP requests, OAuth endpoints, pairing APIs, account APIs and the web application. It authenticates requests, checks account and device policy, applies rate limits and decides whether a call may proceed.
Step 4: D1 keeps durable identity and policy.
D1 stores users, paired-device metadata, credential hashes, sessions, OAuth grants, per-device policy, security settings, usage counters and audit metadata. It is not the live transport for tool execution.
Step 5: a per-user Durable Object owns live routing.
Durable Objects coordinate WebSockets, track which paired devices are reachable and forward a tool call to exactly the selected connection.
Step 6: the local agent is the final execution boundary.
The local agent receives an authenticated routed request, checks what it actually exposes and executes the operation through Remote Arc local execution core. File operations, process inspection, terminal commands and undo terminate at the machine itself.
Step 7: the result travels back, not the machine.
The agent returns the specific tool result through the existing outbound connection. Remote Arc can therefore give AI useful access to local state without moving the entire development environment into a hosted VM.
Why split control plane and execution plane?
The hosted side is good at identity, discovery, routing, policy and availability. The local side is the only place that should own operating-system execution. Keeping those responsibilities separate is the core of the architecture.