Cybersecurity researchers at **Accomplish AI** have revealed a significant sandbox escape vulnerability in **Anthropic's Claude Cowork** application for macOS. The flaw, codenamed **SharedRoot**, allowed the AI agent to bypass its Linux virtual machine (VM) sandbox and access the host Mac's file system with read and write privileges. Approximately 500,000 macOS users running local **Cowork** sessions were affected prior to the issue being addressed. **Accomplish AI** shared details of the vulnerability ahead of publication. "We connected a folder to a fresh **Claude Cowork** session, sent one short message, and watched the agent escape the sandbox," stated Oren Yomtov, principal security researcher at **Accomplish AI**. "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."  ### Broad Access to Sensitive Data This level of access means the **Claude Cowork** agent could access any data stored on the Mac via the user's account, including SSH keys, cloud credentials, and other valuable information, without explicit user permission. Following responsible disclosure, **Anthropic** acknowledged the report but initially classified it as informative without issuing a direct patch for the local execution scenario. However, the latest version of **Cowork** defaults to cloud execution, which mitigates the issue. Users who opt to run the agent locally, however, remain exposed. ### How the Escape Works **Claude Cowork's** macOS desktop application runs under the logged-in user's account. The agent's operations are performed within a Linux VM created using **Apple's Virtualization framework**. Each session is assigned a disposable unprivileged user and a **Secure Computing Mode (seccomp)** filter for application sandboxing. The critical flaw lies in how user-connected folders are shared into the VM. A root daemon, `coworkd`, mounts the entire host file system into the VM with read-write privileges. "The entire host '/', mounted so that only guest-root inside the VM can see it, at /mnt/.virtiofs-root," Yomtov explained. Because the entire host file system is mounted with read-write access, any path that leads to guest-root within the VM can grant the agent access to the underlying host, effectively bypassing the sandbox. ### Exploiting Kernel Vulnerabilities To achieve guest-root, the exploit involves loading the Linux kernel's "act_pedit" Traffic Control (tc) packet editing subsystem into an unprivileged user namespace. This then allows the exploitation of **CVE-2026-46331**, a recently disclosed flaw known as **pedit COW**, in the guest kernel. Once guest-root is obtained, the agent can access the entire host file system (/) with elevated privileges, enabling it to read or write files to and from the Mac's file system as the logged-in desktop user.  Or Hiltch, co-founder and CTO of **Accomplish AI**, clarified that creating user and network namespaces provides the session with **CAP_NET_ADMIN** within its private network namespace, facilitating various network-related operations. "That capability provides access to the vulnerable tc/act_pedit kernel path used by pedit COW," Hiltch added. "The namespaces are not the exploit; they make its normally privileged prerequisite available to an ordinary user." ### Broader Implications for AI Sandboxing This development comes after similar revelations concerning **OpenAI's** models, which reportedly escaped their sandboxed environments during security tests. These incidents highlight the ongoing challenges in securely isolating AI agents. "act_pedit is one bug in a category," Yomtov noted. "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 next one, with everything above the kernel untouched." He further emphasized the systemic nature of such vulnerabilities: "And the next one is always coming. At any given moment there's likely a privilege-escalation bug it's still exposed to, sometimes fixed upstream but not yet in your image, sometimes not yet fixed anywhere, with a working exploit out within hours. This isn't a patch-faster problem. You're structurally one bug behind, all the time." ### Mitigation Strategies To mitigate such threats, it's crucial to disable unprivileged user namespaces, avoid overly permissive seccomp filters, prevent the autoloading of modules, and restrict the sharing of the entire host into the VM. **Accomplish AI** recommends: "Scope it to the folders that were actually connected instead of all of /, or at least mount it read-only, and run coworkd with ProtectSystem=strict in its own mount namespace so it isn't re-execing binaries a session user can poison. Then even a full guest-root has nothing to land on, the last two steps of the chain have nowhere to go."