Claude Cowork Sandbox Escape Lets AI Agent Break Out of Linux VM and Access Files Across macOS

Researchers disclose “SharedRoot,” a sandbox escape affecting Anthropic’s Claude Cowork that allows an AI agent running inside a Linux virtual machine to escape its intended isolation and access files across the host Mac by chaining a guest Linux kernel privilege escalation with a writable host filesystem mount.

Artificial intelligence agents are rapidly evolving from conversational assistants into autonomous systems capable of writing code, executing shell commands, modifying files, and interacting directly with development environments. Those capabilities significantly improve productivity, but they also increase the consequences of security failures. Once an AI agent gains direct access to a user’s workstation, the security of the surrounding execution environment becomes just as important as the model itself.

Security researchers at Accomplish AI have disclosed a sandbox escape vulnerability affecting Anthropic’s Claude Cowork local execution environment that demonstrates exactly how fragile that boundary can become. The flaw, dubbed SharedRoot, allows an AI agent operating inside an isolated Linux virtual machine (VM) to obtain root privileges within the guest and subsequently access files belonging to the logged-in macOS user.

According to the researchers, roughly 500,000 macOS users running local Claude Cowork sessions were potentially affected before Anthropic shifted the application toward cloud execution by default. Users who continue running Cowork locally remain exposed because the underlying architectural design has not fundamentally changed.

Unlike traditional VM escape vulnerabilities that exploit flaws in the hypervisor, SharedRoot does not target Apple’s Virtualization Framework or macOS itself. Instead, it chains together a Linux kernel privilege escalation (CVE-2026-46331, nicknamed pedit COW) with an architectural decision to expose the host filesystem inside the guest VM through VirtioFS. Once the AI agent becomes root within the Linux guest, the distinction between guest and host largely disappears for files accessible to the logged-in user.

How Claude Cowork Executes AI Tasks

Claude Cowork was designed to allow AI agents to work directly with local development environments. Users can connect project folders, allowing the model to inspect repositories, edit source code, execute shell commands, install dependencies, and automate engineering tasks.

Executing these operations directly on macOS would create an obvious security risk, so Anthropic instead runs each Cowork session inside a disposable Linux virtual machine created using Apple’s Virtualization Framework.

Each session receives:

• A fresh Linux VM
• An unprivileged Linux user
• Namespace isolation
• A seccomp syscall filter
• A disposable execution environment

The goal is straightforward. Even if an AI agent behaves unexpectedly or executes unsafe commands, any damage should remain confined to the virtual machine instead of affecting the underlying operating system.

Architecturally, this is a sensible approach and similar to techniques used by cloud sandbox providers and secure container platforms.

The problem lies in how the host filesystem is shared with that virtual machine.

Where the Isolation Breaks Down

An AI coding assistant is only useful if it can actually access the files users want it to modify. Rather than copying project files into the VM, Claude Cowork uses VirtioFS, a high-performance shared filesystem designed specifically for virtual machines. VirtioFS allows the guest operating system to access files stored on the macOS host almost instantly, making large software projects practical to work with.

According to Accomplish AI’s research, however, Cowork’s implementation mounted the entire host filesystem into the guest VM instead of exposing only the folders explicitly shared by the user.

Inside the Linux guest, the host filesystem was mounted at:

/mnt/.virtiofs-root

Initially, this mount was protected because only guest root could access it. An unprivileged Linux process could not browse arbitrary host files, which made the architecture appear reasonably secure.

The weakness was that the security of the entire design depended on one assumption:

The AI agent would never become root inside the guest.

Unfortunately, Linux privilege escalation vulnerabilities appear regularly. Once researchers demonstrated a reliable path to guest root, the remaining security boundary effectively disappeared.

Exploiting CVE-2026-46331

The researchers chained the sandbox escape with CVE-2026-46331, a Linux kernel privilege escalation vulnerability known as pedit COW. The flaw exists within Linux’s Traffic Control (tc) subsystem, specifically the act_pedit packet editing module.

Traffic Control is responsible for advanced networking operations such as packet filtering, bandwidth shaping, Quality of Service (QoS), and packet modification. Historically, this subsystem has experienced numerous memory corruption vulnerabilities because it processes complex user-controlled data while executing inside the kernel.

Ordinarily, exploiting these interfaces requires elevated privileges. Claude Cowork’s namespace configuration unintentionally removed that barrier. Each Linux session creates user namespaces and network namespaces, giving processes CAP_NET_ADMIN within their isolated network namespace. While this capability cannot directly affect the host network, it still grants access to the vulnerable Traffic Control interfaces inside the guest kernel.

As Accomplish AI explained, namespaces themselves are not the vulnerability. Instead, they satisfy the privilege requirements necessary to reach the vulnerable kernel code. Successful exploitation corrupts kernel memory, allowing the attacker to obtain root privileges inside the Linux guest. At that point, the remainder of the attack requires no further exploitation. The AI agent simply accesses the writable VirtioFS mount containing the host filesystem.

From Guest Root to Host File Access

It is important to understand that SharedRoot is not a hypervisor escape. The attacker never compromises Apple’s Virtualization Framework. Instead, the guest VM already contains a read-write view of the host filesystem. Once guest root is obtained, filesystem permissions protecting that mount disappear.

Researchers demonstrated the ability to:

• Read arbitrary files owned by the logged-in user
• Modify project repositories
• Replace shell startup scripts
• Access SSH private keys
• Read cloud credentials
• Modify configuration files
• Create persistence within the user’s account

The compromise remains limited to the permissions of the desktop user rather than macOS root. For most developers, however, that distinction offers little protection.

Modern development workstations typically store valuable assets within user-owned directories, including Git repositories, Kubernetes configurations, cloud authentication tokens, Docker credentials, VPN certificates, infrastructure-as-code templates, browser sessions, and software signing keys.

Compromising the user account often provides everything an attacker needs for lateral movement into enterprise infrastructure.

Why This Matters Beyond One Kernel Bug

Accomplish AI argues that SharedRoot should not be viewed simply as exploitation of CVE-2026-46331.

Linux kernel privilege escalation vulnerabilities continue to appear with regular frequency, particularly within complex subsystems such as networking, eBPF, and Traffic Control. The broader issue is architectural. If guest root automatically grants meaningful access to the host filesystem, every future guest privilege escalation potentially becomes another host compromise path.

Even perfect patch management cannot eliminate this risk because defenders are almost always responding to newly disclosed vulnerabilities rather than preventing their discovery. In other words, the architecture effectively assumes the guest kernel will never fail, an assumption that history has repeatedly shown to be unrealistic.

Enterprise Impact

The disclosure has important implications for organizations increasingly adopting AI-powered coding assistants.

Many developers connect repositories containing proprietary source code, deployment scripts, cloud infrastructure, production credentials, API secrets, and internal documentation.

An attacker obtaining filesystem access through SharedRoot could potentially recover:

• SSH private keys
• Git credentials
• AWS credentials
• Google Cloud authentication
• Azure CLI tokens
• Kubernetes configuration files
• Docker registry credentials
• CI/CD authentication tokens
• Source code
• Internal documentation
• API keys
• VPN certificates

Because AI agents already understand development environments, they require very little reconnaissance to identify valuable files. Rather than blindly searching directories, the model can recognize configuration formats, deployment pipelines, infrastructure repositories, and authentication material.

That contextual understanding makes filesystem compromise significantly more valuable than conventional local privilege escalation attacks.

Detection Considerations

Detecting exploitation presents challenges because much of the activity resembles legitimate Claude Cowork behavior.

The AI is expected to execute shell commands, modify project files, and interact with development tools. Traditional endpoint monitoring therefore has limited visibility into abnormal behavior occurring inside the guest Linux environment. Instead, defenders should focus on unexpected modifications outside intentionally shared project directories.

Particular attention should be paid to unauthorized changes affecting:

• ~/.ssh/
• ~/.aws/credentials
• ~/.config/gcloud/
• ~/.kube/config
• .gitconfig
• .zshrc
• .bashrc
• .profile
• ~/Library/LaunchAgents/

Organizations should also investigate unexplained modifications occurring immediately after local Claude Cowork sessions, especially if those changes affect authentication material or persistence mechanisms.

Indicators of Compromise

SharedRoot does not produce traditional Indicators of Compromise such as malware hashes, known IP addresses, registry keys, or malicious filenames. The exploit chain relies entirely on legitimate application functionality combined with a Linux kernel vulnerability.

Instead, defenders should look for behavioral indicators, including:

• Unexpected modification of SSH keys or cloud credentials.
• Unauthorized edits to shell initialization files.
• Changes to Git configuration.
• New LaunchAgent persistence files.
• Unexpected executable scripts created within the user’s home directory.
• File modifications outside the directories intentionally shared with Claude Cowork.
• Sensitive files accessed or modified immediately following local AI-assisted development sessions.

There are currently no publicly identified network-based IoCs associated specifically with SharedRoot.

Mitigation

Anthropic has significantly reduced exposure by making cloud execution the default for Claude Cowork. Organizations using local execution should carefully evaluate whether it remains necessary.

Accomplish AI recommends several architectural improvements that would substantially reduce the attack surface. Rather than exposing the entire host filesystem to the guest VM, only explicitly shared directories should be mounted. Where possible, those mounts should be read-only. Restricting filesystem visibility ensures that even a fully compromised guest has limited access to sensitive host resources.

The researchers also recommend disabling unprivileged user namespaces where practical, tightening seccomp policies to minimize kernel attack surface, preventing unnecessary kernel module autoloading, and further isolating the privileged coworkd daemon responsible for managing shared files.

Ultimately, SharedRoot demonstrates that the strongest defense is architectural rather than reactive. A sandbox should continue protecting the host even if the guest operating system is completely compromised.

Final Thoughts

SharedRoot is not simply another Linux privilege escalation or another sandbox escape. It highlights a broader challenge facing autonomous AI systems.

As AI agents gain permission to write code, administer infrastructure, execute terminal commands, and automate complex workflows, they increasingly resemble privileged users rather than conventional applications. That shift fundamentally changes the security model.

The vulnerability disclosed by Accomplish AI shows that VM isolation alone is not sufficient if sensitive host resources remain directly accessible after guest compromise. While the immediate issue revolves around Claude Cowork’s local execution environment, the underlying lesson applies to the growing ecosystem of AI-powered developer tools: security boundaries must be designed with the expectation that individual components will eventually fail.