Remote ArcBLOG
Remote Arc blog
Engineering notes, architecture decisions, security trade-offs and product reasoning from building a controlled Remote MCP bridge between AI clients and real computers.
The articles explain why Remote Arc separates the hosted control plane from local operating-system execution, how OAuth and paired-device identities fit together, why terminal access is treated differently from narrower file tools, and where durable task execution stops being the same thing as fresh AI reasoning.
Use these notes when you want the implementation rationale behind the product documentation rather than only setup instructions.
- Could AI become the next compiler?
A thought on how code may recede into the background, why prompts may only be a transition, and what this could mean for Remote Arc.
- Why Remote Arc chose Go: measured against TypeScript on Mac and Windows
Native Go versus TypeScript Agent benchmarks on Intel Mac and Windows: the Windows regression and fix, atomic/durable write trade-offs, memory residency and unanswered L3 questions.
- Why I built Remote Arc: AI should reach your computer without owning it
Why Remote Arc exists: controlled access from AI clients to real computers without surrendering the security boundary.
- Remote Arc vs OpenClaw: two different layers of the AI stack
Remote Arc and OpenClaw can both help AI act on computers, but they own different layers: a persistent real-computer agent runtime versus a self-hosted assistant and agent gateway.
- How Remote Arc keeps AI access powerful without exposing your computer
How Remote Arc combines outbound-only connectivity, OAuth, per-device permissions, protected paths, local undo and audit metadata for controlled AI access.
- How Remote Arc works: Worker, Durable Objects, OAuth and the local agent
A request-by-request walkthrough of Remote Arc architecture: Remote MCP, OAuth, Cloudflare Worker, D1, Durable Objects, the local agent and OS execution.