What a single message reached
On July 23, the security firm Accomplish disclosed a flaw it named SharedRoot. Its principal researcher, Oren Yomtov, described the test plainly: they connected a folder to a fresh Claude Cowork session, sent one short message, and watched the agent escape the sandbox.
Claude Cowork runs its agent inside a Linux virtual machine on the Mac, built on Apple's own virtualization framework. Each session gets an unprivileged user and system-call filtering, which is what makes the word sandbox feel earned. The problem was not the box. It was what the box could see.
The entire host filesystem was mounted into that machine with read and write access. From inside, the agent reached SSH keys, cloud credentials, API keys, source repositories and anything else the logged-in account could touch. By the firm's count, around 500,000 people had run Cowork locally before the exposure was addressed.
Why no fix was shipped
Anthropic received the report and closed it as informative. In bug-bounty terms that is an acknowledgement without a dedicated patch, and the company placed it inside the thirty-day window its programme reserves for such cases.
Its answer was architectural rather than corrective. The current version of Cowork defaults to running the agent in Anthropic's cloud, and the researchers agree that this local escape path does not appear to apply there. The default moved the risk off the customer's machine for anyone who accepts it.
That leaves a clean line down the middle. If your developers run the agent in the cloud default, this specific escape is not their problem. If they opt into local execution, for privacy or offline work or habit, they carry the whole exposure, and no update is coming to remove it for them.
The boundary was a mount, not a wall
The instructive detail is how ordinary the weakness was. The host filesystem was shared into the virtual machine so that only the root user inside the guest was meant to see it. The escape simply became root inside the guest, using a known Linux kernel flaw tracked as CVE-2026-46331, and the mount did the rest.
The lesson for defenders is not a single vendor's mistake but the shape of it. A sandbox that shares the whole host is only as strong as the assumption that nothing inside will ever gain root. With an agent that reads untrusted content and acts on it, that assumption is exactly the one you should not make.
What to lock down before running it locally
Treat any machine that runs a local agent as if the agent can read the home directory, because in this case it could. Keep SSH keys and cloud credentials off developer laptops that run untrusted-content agents, or scope those agents so the host filesystem share is limited to the connected folders and mounted read-only.
Where the platform allows it, the researchers recommend disabling unprivileged user namespaces, tightening the system-call filter, and preventing unused kernel modules from loading on demand - the steps that would have blocked this particular chain. These are configuration controls, which means they sit with you, not with the vendor.
The reporting duty sits with you too. Under NIS2 across the European Union, and DORA for financial firms, a leaked developer credential that reaches production is your incident to declare, on your clock. In the United Kingdom the NCSC frames the same expectation. The sandbox was sold as safety; the accountability was always yours.
Read next: The Door Left Open Was the Package Registry | An AI Just Ran a Whole Ransomware Attack Alone
