Claude Cowork Just Did the Thing I Said Remote Control Wasn’t Doing

On August 19 I wrote a piece arguing that Claude Code’s Remote Control feature was not, despite how the demos read, a cloud migration. My claim was specific: “local execution stays local; only session state gets synced,” and I framed that as a deliberate security boundary — credentials, filesystem, tool access all stay pinned to your machine, and the sync relay only ever moves conversation and approval events. I called it a pattern I’d reuse.

Six weeks later, Anthropic shipped the opposite architecture for a sibling product, and the framing in the coverage made it sound like a reversal. It isn’t one. But it took writing out the difference to be sure.

What actually changed, and when

On October 5, Simon Willison published a quote from Anthropic’s Felix Rieseberg describing Cowork’s old architecture plainly: inference ran in the cloud, but the actual execution VM ran locally, on your machine — costing disk space and battery, and stopping dead the moment you closed your laptop. The new version, rolling out October 6 on Pro and Max plans by default, moves both inference and the VM to the cloud. Anthropic’s own support documentation spells out the split precisely: cloud-side now covers task execution, scheduled tasks (no device has to stay awake for them to fire), and session/file sync across devices. Staying local, and requiring the desktop app to be open, are four specific things: local file read/write in connected folders, local MCP connectors and plugins, in-app browser use, and computer use — clicking and typing on your actual screen. When a cloud session needs something from your local machine, the desktop app handles that one tool call and the fetched copy gets deleted afterward, per Anthropic’s retention policy.

That’s not “we decided local execution doesn’t matter.” It’s a narrower claim: for this product, the set of things that genuinely require your machine is small and well-defined, and everything outside that set moves to a sandbox that doesn’t care whether your laptop is open.

The actual design question, restated

My August piece asked, implicitly, “should execution live where the user’s resources live, or where the agent’s compute lives?” I answered it as if there were one right answer. There isn’t — there’s one right answer per workload, and the variable that decides it is how often the task’s primary resource is something only your machine has.

For Claude Code driving a coding session, the primary resource is almost always local: your actual repository, your actual build toolchain, credentials scoped to your actual machine, a long-running process whose state you want to inspect and intervene on in real time. Remote Control’s job is to let you supervise that local thing from elsewhere, not replace it. Keeping execution local there isn’t conservatism, it’s just accuracy about where the real work has to happen.

For Cowork, the primary resource is usually incidental: fetch this file, check this calendar, draft this email, run this multi-step task overnight. The local machine shows up as an occasional dependency, not the substrate the whole task runs on. Pinning execution to a laptop that might be closed, asleep, or out of battery is a worse fit for that shape of work than a per-session cloud sandbox with a thin local tool-call proxy for the rare moment it needs your disk.

How this compares to what else is out there

The “isolated cloud sandbox per session, with a narrow local handoff for device-specific resources” shape is close to what GitHub’s cloud coding agents and OpenAI’s Codex cloud already do, and to Cursor’s background agents — all three decouple agent execution from the user’s machine and run it in a container the agent fully owns. The detail that’s different in Anthropic’s version, per their own documentation, is the explicit tool-call-level boundary: rather than syncing a filesystem snapshot or requiring a git-based checkout to move state back and forth, the desktop app answers one specific request at a time, only while it’s open, and nothing persists locally afterward. It’s a narrower, more auditable local footprint than “clone the repo into the cloud VM,” which matters if you’re thinking about this pattern for something more sensitive than drafting emails.

What I’d actually change in my August conclusion

Not the core claim — I still think Remote Control’s “sync state, not execution” boundary is the right call for a tool whose entire value proposition is supervising code that must run on your machine. What I’d change is the throwaway line where I said the pattern “generalizes well beyond coding agents, to any tool where you want mobile oversight of a process that must stay local.” The qualifier I skipped past is the one that matters: must stay local. Cowork is proof that a lot of agent workloads only sometimes touch something local, and for those, the sync layer isn’t the ceiling on the architecture — it’s one option among several, and cloud-resident execution with a narrow local handoff can be the better default.

The practical test I’d apply before picking either shape for something I’m building: list what the task actually needs from the user’s machine, and ask whether that need is constant or occasional. Constant — a live process, a credential that can’t leave the box, a repo you’re actively editing — keep execution local and sync only the control plane, the way Remote Control does. Occasional — a file lookup, a screenshot, a one-off local action inside an otherwise self-contained task — a cloud sandbox with a narrow callback, the way Cowork now does, will hold up better against a closed laptop than a sync relay ever will.

Sources: Felix Rieseberg via Simon Willison, Oct 5, 2026, Anthropic support — Use Claude Cowork on web, desktop, and mobile