Two Sandboxes, One Goal: What Became of My Forecast

In February, I wrote down where the sandboxes of Claude Code and Cowork might be heading. Five options, one forecast. I didn’t publish the text back then. Now, eight months later, I’m putting it next to reality. Some things I got right, some I didn’t. And the most important development wasn’t on my list at all.

Where things stood in February

In “How Secure Is the Claude Code Sandbox on the Mac?” I had looked at both sandboxes from the inside. The result: two products, two security models. Claude Code protects at the process level, with Apple’s Seatbelt on the Mac and bubblewrap on Linux. Cowork runs in a full Linux VM. Both route their network traffic through a proxy with an allowlist.

My question afterwards was: will it stay this way, or will the two approaches converge? I saw five paths. Here they are, each with what I thought back then and what holds today.

Option 1: A VM for Claude Code, like Cowork

Back then: The obvious idea, but a bad trade for developers. A VM breaks tools that need the host and costs disk space and startup time. Too heavy for a tool that’s supposed to feel like a fast terminal.

Today: Claude Code hasn’t gained a built-in VM. If you want a VM, you get it another way: cloud sessions run in a VM operated by Anthropic. Locally, the docs point to your own VMs or containers.

What happened with Cowork is more interesting. In July 2026, Accomplish AI published a vulnerability called “SharedRoot”. It combined a flaw in the VM’s Linux kernel with a writable folder that Cowork mounts from the Mac. The result: the agent got out of the VM and reached files of the logged-in Mac user. Reports disagree on whether and how Anthropic fixed it. Several sources say that newer Cowork versions execute in the cloud by default, which sidesteps the local path.

My takeaway: a VM is a strong boundary, but every opening you drill into it weakens it. A writable folder from the host is such an opening.

And something else shifted with Cowork, in the direction of Claude Code. According to Anthropic, Cowork’s agent loop now runs on the host, and only code execution stays in the VM. Local MCP servers have moved to the host as well. So the two products really did move closer together, just from the other side than I expected.

Verdict: I was right that Claude Code wouldn’t get a local VM. I underestimated how vulnerable even a VM becomes once you mount folders from the host.

Option 2: Docker Sandboxes

Back then: New and technically exciting, because an agent can build containers inside it without reaching the host’s Docker daemon. But a Docker product, so vendor dependency, and it required Docker Desktop.

Today: Docker Sandboxes have become a standalone product. According to Docker, they run on macOS, Windows and Linux, each sandbox in its own microVM with its own Docker daemon. Docker Desktop is no longer required. Supported agents include Claude Code, Codex, Gemini CLI and GitHub Copilot.

And Anthropic now mentions them in its own documentation, in the section on virtual machines, as one way to run Claude Code in isolation.

Verdict: Partly came true. Docker Sandboxes have become an accepted path, but not the standard. Anthropic lists them as one option among several.

Option 3: Apple Containers

Back then: Every container in its own lightweight VM, native on the Mac. A candidate to replace Seatbelt. But only from fall 2026, only on Apple Silicon and only on the Mac.

Today: Apple’s container is here. Anthropic doesn’t use it. On the Mac, Claude Code still protects with Seatbelt.

It’s being used anyway, by the community and by me. My coding agents now run in Apple containers. How that’s built and what I tested in it is covered in “The Wall from Inside”.

Verdict: Wrong about Anthropic. Right that the technology is up to the job.

Option 4: Status quo

Back then: Seatbelt and bubblewrap work, cost hardly any time and cover the main threats. The risk: a shared kernel, and Seatbelt has no official successor at Apple.

Today: The status quo has held. Claude Code’s Bash sandbox still uses Seatbelt and bubblewrap, and it’s off by default. That it holds up in everyday use is something Anthropic had already reported in October 2025: in internal usage, the sandbox reduced permission prompts by 84 percent.

What’s new is the “sandbox runtime”. It puts the same boundary around the entire Claude Code process, including file tools, MCP servers and hooks, not just shell commands. It’s still labeled beta.

Verdict: Came true. I had dismissed this as the convenient option. It turned out to be the most stable one.

Option 5: Hybrid – tiered isolation

Back then: A light sandbox for interactive work, a VM for unattended runs. My forecast: this is the most likely path. What was missing was a single command that picks the right level depending on the situation.

Today: The tiers exist, and they’re official. The Claude Code docs have a dedicated page comparing six levels: Bash sandbox, sandbox runtime, dev container, custom container, VM and cloud session. Plus a table of which level fits which goal. For unattended runs, it recommends a container, a VM or the sandbox runtime.

The single command doesn’t exist. If you want to change the level, you change the environment yourself.

Verdict: Came true. The tiers exist, you just have to pick one yourself.

What I didn’t see coming

My five options had one thing in common: they all asked how strong the wall needs to be. But the most important innovation since then wasn’t a stronger wall. It was a bouncer.

In March 2026, Claude Code got an auto mode. A second model, the classifier, checks every action before it runs and blocks anything that escalates beyond the task. Anthropic cites a number that surprised me: users used to approve roughly 93 percent of all permission prompts. Prompts you almost always approve hardly protect anything. According to Anthropic, the classifier catches about 83 percent of overeager actions before they run.

What matters is how Anthropic positions it. The docs say the classifier is a per-action control, not an isolation boundary. It doesn’t replace the sandbox, it sits on top of it. That’s exactly the interplay I described in “Cage, Wall, Bouncer”.

In hindsight, this was foreseeable. I was looking at the technology. The development came from people: from the experience that permission prompts wear you down.

Scorecard

February forecast	Status in October
Claude Code won’t get a local VM	came true
Docker Sandboxes become a path for unattended runs	partly: officially mentioned, but one option among several
Apple Containers replace Seatbelt	did not come true
The process sandbox remains the foundation	came true
Tiered isolation becomes the path	came true, you pick the level yourself
Developer and knowledge-worker tools converge	came true, but from Cowork’s side: agent loop on the host, only code execution in the VM
–	not foreseen: auto mode as a per-action check

What I take away from this

My starting question was whether the two sandboxes would converge. The answer: yes, but differently than I thought. Claude Code didn’t move into a VM. Cowork moved partly out of one.

I take two things away from this.

First: the sandbox question was never just a question of strength. A VM is stronger than Seatbelt, but only as strong as its openings. In its own retrospective, Anthropic writes a sentence I want to remember: the weakest layer is the one you built yourself. For Anthropic, it wasn’t a hypervisor or a kernel, but a custom proxy.

Second: the next layer didn’t come from below, it came from above. It wasn’t a thicker wall that made the agents safer, but someone who looks at every action. And that, too, is only one layer of several.

For my own practice, this means: I don’t bet on the one right sandbox. I stack. Process sandbox, a check on every action, a container, separate keys. And I look especially critically at the parts I built myself.