2026-07-30

Claude Cowork’s sandbox break is a reminder that “local AI” has real attack surface

If you build with Claude or are tempted to let an agent touch your files, this report lands in the uncomfortable but useful category. It shows how a local agent workflow can fail in a way that looks subtle at first and then suddenly becomes very serious: once an attacker gets root inside the guest VM, the host Mac can be exposed through a writable filesystem mount.

Key Points

Anthropic’s Claude Cowork had a flaw that let a locally running session escape its sandbox and reach files on the user’s Mac.
Accomplish AI researchers said the attack, which they call SharedRoot, used a Linux kernel bug to gain root inside the virtual machine.
Once inside the guest as root, Claude could access a writable VirtioFS mount of the Mac’s filesystem and read or write files outside the approved folder.
The researchers said potentially exposed data included SSH private keys, cloud credentials, browser data, and other user-accessible material.
The attack did not bypass Apple’s virtualization system directly; it abused the way Cowork mounted the host filesystem into the VM.
Anthropic made cloud execution the default for Cowork sessions on July 7, which reduces exposure to this specific local-escape path.
Accomplish AI reported the issue to Anthropic, and Anthropic closed it as “Informative,” according to the researchers.
The researchers recommended narrower folder mounts and read-only mounts where possible.
Users who ran local Cowork sessions with untrusted files should consider rotating credentials that may have been reachable.

My Take

What strikes me is that this is less a “Claude is broken” story and more a “agentic desktop tooling is a security minefield” story. The weak point wasn’t some abstract AI behavior; it was the very ordinary reality of running privileged plumbing around a local VM and then mounting the host filesystem into it. That’s the kind of thing that feels safe right up until it doesn’t.

I think Anthropic’s move to make cloud execution the default is the right direction, at least as a damage-reduction measure. If the agent isn’t sitting inside your local VM, this particular escape route disappears. But that doesn’t magically make file access safe. The minute you give an agent broad access to keys, browser profiles, or synced credentials, you’re trusting a lot more than most people realize.

What I’d actually do here, if I were using Claude in a developer workflow, is keep local execution on a very short leash. Only mount the exact folder I need. Prefer read-only whenever the task allows it. And I’d be conservative about anything that can touch SSH keys, cloud accounts, or browser state. Those are the juicy bits, and they’re exactly what a successful breakout would aim for.

I’m also mildly skeptical of the “it was only informative” response, because from a user’s perspective this sounds pretty consequential. Perhaps Anthropic judged the path too dependent on a separate Linux flaw, but in practice the combination matters. If another root path exists inside the guest, the same host-exposure pattern could come back.

The takeaway is simple: Claude-style agents are powerful, but their permission model is not something to hand-wave. Treat local agent execution like you’d treat any other privileged integration. Tight scope, minimal mounts, and assume anything reachable may eventually be reached.