Coding agent runtime, local VM vs cloud sandbox: what moves across the boundary after Cowork went cloud-only
Tools in this post
As of 16 October 2026, a team deciding where its coding agents run should keep interactive work on developer machines with the OS sandbox switched on, and send repository-scoped tasks that end in a pull request to a vendor's cloud sandbox. The condition is what the task needs that a cloud VM cannot reach: a private network, local MCP servers, interactive SSO or a non-GitHub host. Anthropic forced the choice for Cowork users on 6 October, when it moved every new Claude Cowork task on Pro and Max plans into its cloud, with no setting to switch back.
What changed when Cowork moved its VM into the cloud?
Claude Cowork used to run its agent loop on the user's computer and its shell commands in a Linux VM on that computer. Since 6 October 2026, new Cowork tasks on Pro and Max run the loop and the VM in a per-session sandbox on Anthropic's servers, destroyed when the session ends (help center). Tasks started locally before that date stay local until they finish.
Felix Rieseberg, who works on Claude Cowork at Anthropic, gave the reason on X the day before: people "didn't love the disk, battery, and performance cost of running the VM locally. Also, people didn't love that closing your laptop means the work stops." The desktop app stays in the loop: "When the VM needs something on the users' device (like a file), the desktop app is responsible for that file access tool call" (quoted by Simon Willison). It fetches a copy of each file the task needs, only while the app is open.
What the move cost, per Anthropic's notes on cloud Cowork: working files Claude does not hand back are discarded, a session cannot switch between local and cloud halfway, and local folders, local MCP servers and browser use work only through the desktop app while it is open. Anthropic's answer for local-only work is Claude Code: download the task data and run /port-task-data. Team and Enterprise plans keep local execution, with cloud sessions in beta.
Four places the agent loop can run, and what each commits a team to
A coding agent's runtime is where its loop runs and where its tools execute, and the two have come apart. There are four arrangements as of October 2026: everything local, everything in the vendor's cloud, the vendor's loop driving your machine, and a sandbox or runner you run yourself. Each one decides where files, credentials and session state live.
| Local | Vendor cloud sandbox | Vendor loop, your machine | Sandbox or runner you run | |
|---|---|---|---|---|
| Examples | Claude Code, Codex CLI, Aider | Claude Code on the web, Codex Cloud, Cursor Cloud Agents, Copilot cloud agent, Jules, Devin | Cursor Self-Hosted Machines, Devin Outposts | Claude Code self-hosted environments, E2B, Daytona, Modal, OpenShell, Mecatl |
| Files | Your disk | A fresh git clone | Your machine | Whatever you mount or clone |
| Credentials | Your keychain, gh, SSH |
Swapped in at a vendor proxy, or env vars | Stay on your machine | Your design |
| Session state | Local history | Vendor account | Vendor account | Your store |
| Keeps running with the laptop shut | No | Yes | Only if the worker is up | Yes, if hosted off the laptop |
| Cost | Plan or API tokens | Plan usage, API prices or credits | Plan plus your hardware | Per-second compute plus tokens |
| Status | Shipped | Shipped (Cowork for Team and Enterprise in beta) | Shipped | Claude Code's runner in public beta, OpenShell at 0.1.x |
In the hybrid column, Cursor's docs say "Cursor runs the agent loop, inference, and planning" while your worker edits files and runs commands (docs), and Devin Outposts works the same way. Claude Code's self-hosted environments go further: the runner starts a Claude Code process on your host, so the loop runs there too, while Anthropic queues the session, streams its events and serves inference (docs). Session content still goes to the vendor in all three. The durable harness post covers the session-state side.
A cloud sandbox gets a clone, not your disk
A vendor cloud sandbox works on a copy of the repository, not on the developer's checkout. Claude Code's cloud VM "clones your current directory's GitHub remote at your current branch, not your local checkout, so push first"; without GitHub it accepts a bundle under 100 MB with untracked files left out (docs). The VM has about 4 vCPUs, 16 GB of RAM and 30 GB of disk, and costs nothing beyond plan usage.
What stays behind, per Anthropic's cloud environments page: the user's ~/.claude/CLAUDE.md, user skills, MCP servers added at local or user scope, and interactive logins such as AWS SSO, which "can't run in a cloud session". Anything the agent needs has to be committed to the repository or configured in the vendor's environment.
Credentials are where the vendors differ most:
- Claude Code cloud keeps GitHub tokens on Anthropic's servers and swaps a scoped credential for the real one at its proxy; network secrets are added after a request leaves the VM. Plain environment variables are another matter: "Anyone who uses the environment can read the values."
- Codex Cloud gives programs a placeholder that its proxy replaces for allowed destinations (docs).
- Cursor Cloud Agents load secrets as environment variables; Runtime Secrets are redacted from transcripts but "still visible to users interacting with the agent's environment via the Terminal" (docs).
- Meta Muse, a consumer agent rather than a coding tool, gives each user a cloud VM in which code "only ever sees a "surrogate" token", replaced with the real credential at the network boundary (Meta).
Egress has a fixed exception too. Claude Code's cloud sessions reach the Anthropic API even with network access set to None, which "may allow data to exit the VM".
Local runtimes keep private networks, local tools and SSO working
Teams still run the agent locally because the cloud VM cannot reach what their work depends on. The vendors' own pages list the reasons when they explain their self-hosted options: internal services, databases and registries behind the firewall, GPUs or Macs for iOS builds, and checkouts that have to stay on company hardware. Claude Code's hosted cloud sessions also fail outright for organizations with IP allowlisting, and are unavailable under Zero Data Retention, HIPAA or customer-managed keys.
The OpenHands team argued the engineering case in its SDK paper: forcing every tool call into Docker "corrupted sessions" when agent and sandbox diverged, and fit poorly with MCP, which "assumes agents can execute actions locally". Its rule is "Sandboxing should be opt-in, not universal", and its own 15-day production comparison found 61% fewer system-attributable failures after the change. The cost of local is that the agent runs with the developer's authority. A source study of eleven harnesses found no OS sandbox at all in five of them, Aider and OpenCode among them, and an opt-in one in Claude Code.
On Stackness, five of the eight real members who list Claude Code, my own account among them, also list Docker, and none lists a hosted sandbox, as of 16 October 2026 (data sources). The numbers are small.
Moving a session between local and cloud is mostly one-way
An agent session does not move cleanly between a laptop and a cloud VM. In Claude Code, "you can pull cloud sessions into your terminal with --teleport, but you can't push an existing terminal session to the cloud"; the desktop app's "Continue in cloud" carries the conversation over as a summary. Teleport needs a clean git state and the same repository and account.
The other vendors move diffs rather than sessions. codex apply applies the latest cloud diff to the local repository and exits non-zero on a conflict (commands). Devin's handoff sends the repository, branch and git diff HEAD truncated to 100 KB. Cowork does not switch modes within a session at all, and Anthropic's notice, as quoted by CellCog, said projects and scheduled tasks do not carry over to Claude Code.
OpenShell enforces limits in the kernel, not in the prompt
NVIDIA OpenShell puts an agent in a sandbox whose limits the agent cannot reach, which is the difference from a rule in a prompt or an instruction file. Released as v0.1.0 on 25 September 2026 under Apache-2.0, it limits file access with Landlock, stages network calls through seccomp, runs the workload as a non-root user with no network of its own, and adds credentials only to requests bound for approved endpoints (architecture).
Image: OpenShell system architecture by the NVIDIA OpenShell project, Apache-2.0.
A formal prover blocks auto-approval of any policy change that adds credentialed reach. It runs on Docker, Podman, Kubernetes or a libkrun microVM; the default image ships with no agent installed. On 28 September NVIDIA made it part of its Open Agent Safety Platform, launched with "over 100 industry partners", NVIDIA's own count. OpenAI is not among them in the launch coverage or on NVIDIA's own logo wall, and no source I found says whether it declined.
Mecatl, from Stacklok's Craig McLuckie and Joe Beda, takes the other route: one Apache-2.0 loop that runs "locally, remotely, or on Kubernetes", per its repository, with credentials on the host and tools in an optional microVM (Latent Space). The founders describe their own product there.
The risks: lock-in, cost growth and beta labels
The risks of each runtime are different in kind: cloud runtimes lock work into a vendor's account and git host, rented sandboxes grow with hours used, and the newest options are still in beta. Local runtimes carry the opposite risk, an agent with the developer's own access. A team picking one is picking which of these it can watch.
Lock-in sits in the account and the git host
Cowork's cloud tasks live in the Claude account, not in files, and users reported the first banner about a week before the cutover. Claude Code cloud needs GitHub to clone and open pull requests, and Codex Cloud does not support GitLab or GitHub Enterprise Server yet. Setup scripts, secrets and allowlists do not port between vendors.
Cost grows with parallel tasks and sandbox hours
Claude Code cloud has no VM charge, but "running multiple tasks in parallel consumes more rate limits proportionately". Cursor Cloud Agents bill at API prices, and Copilot's extra credits are "enabled by default". A self-run 2 vCPU, 4 GiB sandbox costs about $0.17 an hour on E2B or Daytona and $0.24 on Modal at list prices (E2B, Daytona, Modal), so ten engineers running one eight hours a day for 21 days spend about $280 to $400 a month before tokens and plan fees.
Several options are still announced or in beta
Claude Code's self-hosted environments are a public beta, cloud Cowork for Team and Enterprise is in beta, OpenShell ships weekly at 0.1.x, and Copilot's cloud agent caps every session at 59 minutes. I found no independent measurement of cloud against local latency; the only figures come from sandbox vendors comparing themselves with rivals.
What would change the recommendation
The recommendation holds while three facts hold: cloud VMs cannot see a private network without extra setup, user-level configuration does not travel, and Claude Code's self-hosted runner is in beta. If that runner leaves beta, regulated teams get the vendor's queue and models with checkouts on their own hardware, and it becomes their default. If Anthropic names a hosting region for cloud Cowork, or restores a local mode on Pro and Max, the data-residency argument changes with it. If OpenShell's microVM backend matures, a self-run sandbox around a local agent becomes the stronger local option. The infrastructure side of each choice sits with the DevOps tools teams list.
What I would do
- If the team works in one GitHub repository and tasks end in a pull request, I would send those tasks to a vendor cloud sandbox and keep secrets in its proxy, never in environment variables.
- If the agent needs internal services, local MCP servers or SSO, I would keep it local with the OS sandbox on, or put it on a vendor-loop worker such as Cursor Self-Hosted Machines or Devin Outposts if the team already pays for one.
- If the team runs Cowork on Pro or Max and needs a task to stay on the machine, I would port it to Claude Code with
/port-task-datanow rather than wait for a local mode. - If several agents need one set of limits, I would put them in a self-run sandbox such as OpenShell and treat its 0.1.x status as a reason to pin versions.
- If nobody can say which of these the team needs, I would start local: a local task can still be pushed to a branch and handed to a cloud sandbox later, while cloud-only work such as Cowork's has no way back to local mode. The containment comparison covers which local sandbox to put around it.
New posts by email
About one email a week with what we published. No account needed.
One email to confirm first. Every email has a one-click unsubscribe.
Which of these do you use?
Nobody on Stackness runs Claude Cowork yet. Tick what you use and be the first.
