SharedRoot; Escaping the Claude Cowork sandbox — Accomplish Blog<br>We connected a folder to a fresh Claude Cowork session, sent one short message, and watched the agent escape the sandbox. From inside the VM it reached the host Mac and read and wrote files all over it, far outside the folder we’d connected, with no permission prompt anywhere. SSH keys, cloud credentials, anything the user’s account can touch.

That’s not supposed to be possible. Cowork runs the agent inside a Linux VM as an unprivileged user, and the promise is that whatever it does stays inside that VM and the folders you hand it. That boundary is the product. Untrusted input isn’t an edge case for an agent, it’s the main case. You want it reading the repo you didn’t write and the PDF someone emailed you. So the boundary is the only thing standing between “the model did something silly” and “the model had my cloud credentials.”

Cowork’s design here is careful. A real VM, an unprivileged session user, a seccomp filter, a brokered mount layer. Most of it holds. What follows is one path through it. Watch how many separate things had to line up for it to exist at all.

The vulnerability has been reported to Anthropic and was closed as “Informative”. Cowork now uses cloud execution by default, and this local escape path does not appear to apply there.

The Chain

How the escape worked

The relevant pieces are simple enough. The app is a normal macOS desktop app, running under your user account. The actual agent work happens elsewhere, in a Linux VM spun up through Apple’s Virtualization framework. Inside that VM each session gets its own throwaway unprivileged user, wrapped in a seccomp filter, and the folders you connect are brokered in as mounts by a root daemon called coworkd. Unprivileged user, restricted syscalls, only your folders in view.

One detail matters more than the rest: the host filesystem gets shared into that VM read-write. The entire host /, mounted so that only guest-root inside the VM can see it, at /mnt/.virtiofs-root. That mount is where the escape happens: the entire host, writable, one privilege boundary away from the sandbox. We named the chain that reaches it SharedRoot.

Fig 1. The entire host filesystem, mounted into the VM and writable. Only the VM's root user can see it, and reaching it is the last move in the escape. This mount is what SharedRoot turns on.

Now, the chain itself.

Start. The agent is running as the unprivileged session user. No bug got us here, this is just Cowork doing its job on the content we gave it.

Get capabilities. The session user calls unshare to create a new user namespace. Inside that namespace it is root, holding the full set of Linux capabilities, CAP_NET_ADMIN among them. The guest allows unprivileged user namespaces, so there is no exploit in this step at all. It’s a kernel feature that could have been turned off, but left on.

Reach the vulnerable code. With CAP_NET_ADMIN in hand it configures a traffic-control (tc) action that uses the kernel module act_pedit. Setting that up runs over a netlink socket, which the permissive seccomp filter allows, and merely referencing the module makes the kernel autoload it. A networking module the sandbox never needed is now loaded and reachable.

Get a write primitive. On this guest kernel act_pedit is vulnerable to CVE-2026-46331, “pedit COW,” a public Ubuntu bug from June. It lets you poison the page cache of a file you’re only allowed to read. So the session user picks a root-owned helper binary it can read but not write, and poisons the cached copy. The on-disk bytes never change, which is part of why it’s quiet.

Turn the primitive into guest-root. This is where it stops being a kernel bug. coworkd runs as root, unhardened, over a view of the same filesystem, the same inodes. In the course of normal work it re-execs that helper, and it runs the poisoned copy. Because the process doing the exec is already root, NoNewPrivs, the thing that normally stops you gaining privilege across an exec, has nothing to bite on. The session user is now root inside the guest.

Leave the VM. Guest-root can see /mnt/.virtiofs-root, the whole host /, shared in read-write. From there it reads and writes the host Mac’s filesystem directly, as the logged-in desktop user.

We ran the full chain end-to-end on our own machine, and it worked.

The chain, end to end. A prompt runs in Cowork's connected folder; seconds later a file written from inside the sandbox lands in the host user's home directory, outside anything the session was granted.

The Reframe

It didn’t have to be this way

There’s a CVE in that chain, but it carries less weight than it first appears.

act_pedit is one bug in a category. The Linux net/sched subsystem throws off this exact shape of privilege escalation on a regular cadence: an autoloadable module, a config path an unprivileged user can reach, a memory bug at the end of it. Patch this one and you’ve fixed this one. The chain re-arms on the...