On July 23, 2026, Accomplish AI published SharedRoot: a Claude Cowork local-session chain where one short message was enough for the agent to leave its Linux VM and read/write the host Mac far outside the connected folder — SSH keys, cloud credentials, home directory — with no permission prompt.
The CVE in the middle matters. The design matters more.
TL;DR — What People Are Asking
| Question | Answer |
|---|---|
| Product? | Claude Cowork local macOS sessions |
| Codename? | SharedRoot (Accomplish AI) |
| Kernel bug? | CVE-2026-46331 pedit COW (guest) |
| Worst mount? | Host / at /mnt/.virtiofs-root R/W for guest-root |
| Report status? | Anthropic closed as Informative |
| Mitigation claim? | New sessions cloud by default; local path may still matter |
| User action? | Prefer cloud · don’t connect secret-rich machines · rotate if exposed |
| PoC here? | No — defensive summary only |
Architecture (Why Escape Was One Privilege Away)
Cowork’s macOS app runs as your user. Agent work runs in a Linux VM (Apple Virtualization): disposable unprivileged session user, seccomp filter, folders brokered by root daemon coworkd.
The critical detail Accomplish documents: the entire host filesystem is shared into the VM read-write at /mnt/.virtiofs-root, visible to guest-root. Reach guest-root → host Mac as the desktop user.
That is why they named the chain SharedRoot.
Chain at a High Level (No Exploit Recipe)
Accomplish’s public write-up walks a multi-step path. In plain language only:
- Session starts as the unprivileged VM user (normal Cowork).
- Unprivileged user namespaces remain allowed → session can obtain powerful capabilities inside a namespace (including networking admin rights needed for the next step).
- A networking / traffic-control path loads a vulnerable guest module covered by CVE-2026-46331 (“pedit COW”).
- That bug class enables page-cache poisoning of a readable helper binary.
coworkd(root) re-execs the poisoned helper during normal work → guest-root.- Guest-root uses the whole-host virtiofs mount to touch the Mac filesystem.
We are not reproducing commands, patches, or payloads. If you need engineering detail, read Accomplish’s post and your kernel advisories — not a blog PoC.
Four Locks That Beat the Next Kernel Bug
Accomplish’s thesis: guest kernels will always be one N-day behind. Patching pedit COW alone re-arms on the next net/sched flaw. Any one of these design locks breaks the class:
| Lock | Effect |
|---|---|
| Disable unprivileged user namespaces | First step fails — no namespace-root / CAP_NET_ADMIN playground |
| Harden seccomp (block unshare/netlink class) | Close the road to the vulnerable subsystem |
Block unused module autoload (install … /bin/false) | Kill whole unused-module LPE category; pattern already used elsewhere in the image |
Don’t share whole host / into the VM | Even guest-root only sees connected folders — highest leverage |
Their product lesson: treat the entire guest (including root) as untrusted; keep the boundary on the host side.
Anthropic Response & Practical Status
- Reported to Anthropic; closed Informative (CVE within recent-public window; hardening framed as defense-in-depth).
- Accomplish states Cowork now uses cloud execution by default, and the local escape does not appear to apply there.
- Local sessions and older builds may still matter for users who opt in or lag updates — verify in-app, do not assume from a headline.
For the wider Cowork risk surface (prompt injection, extensions, audit gaps), see Is Claude Cowork safe? and How to use Cowork safely. Memory/tool exfil is a different class — Memory Heist.
Why Kernel Patching Alone Fails Agents
Accomplish spends pages on a point security teams underweight: AI-assisted vulnerability research compressed the gap between “patch landed upstream” and “working public exploit.” Guest kernels inside agent VMs are rarely on the bleeding edge of distro security updates. If your containment story is “we update the guest when Ubuntu updates,” you are structurally late.
That is why the four locks matter more than CVE-2026-46331 specifically. act_pedit is one bug in a recurring shape: autoloadable module, reachable from an unprivileged configuration path, memory corruption at the end. Kill the shape — namespaces, seccomp, module policy, mount scope — and the next N-day does not automatically become a Mac compromise.
Compare this to cloud agent failures like AgentForger: different layer (identity vs host FS), same moral — agent control planes need boundaries that survive a single bug or a single click.
Local vs Cloud Cowork — Decision Matrix
| Situation | Prefer |
|---|---|
| Laptop holds prod SSH keys, cloud tokens, customer exports | Cloud Cowork (or no Cowork) |
| Processing untrusted PDFs / random GitHub zips | Cloud or air-gapped throwaway machine |
| Regulated data that cannot leave the device | Dedicated hardened local profile or ban Cowork — do not mix with daily driver |
| Personal notes, public docs, throwaway scratch | Local may be fine after you verify session mode |
| MDM-managed corporate Mac | Follow IT policy; assume local agent = endpoint risk |
Accomplish’s claim that new sessions default to cloud is helpful only if users notice the mode and IT can enforce it. Product defaults drift; screenshots lie; check the session indicator.
Incident Response If You Used Local Cowork on a Daily Driver
If your team ran local Cowork against untrusted content before the disclosure window:
- Assume host user-equivalent access was possible for the duration of risky sessions.
- Rotate SSH keys, cloud access keys, package-registry tokens, and browser-saved credentials on that Mac.
- Audit
~/.ssh, cloud CLI configs, and recent file mtimes for unexpected writes (without turning this into a forensics novel — escalate to IR if you see anomalies). - Reimage high-sensitivity endpoints when in doubt; cheaper than debating whether guest-root happened.
- Update Claude Desktop / Cowork and confirm cloud default before re-enabling.
Vendor Due Diligence Questions
Send these to any “local AI agent for the enterprise” vendor:
- Is the entire host filesystem ever mounted into the agent VM? If yes, at what privilege?
- Are unprivileged user namespaces enabled in the guest?
- Is seccomp default-deny or a denylist?
- How fast do you ingest guest kernel CVEs vs host app releases?
- Can MDM force cloud execution and disable local VMs?
“We use a real VM” is table stakes. SharedRoot shows a real VM with a whole-disk mount is still a laptop compromise waiting for the next net/sched bug.
What Teams Should Do
- Prefer cloud Cowork when secrets live on the laptop.
- Isolate local agents on dedicated machines or VMs without production keys.
- Minimize connected folders — never mount
~“for convenience.” - Rotate credentials if you processed untrusted docs/repos in local Cowork before disclosure.
- Vendor questionnaires — ask whether host root is mounted into agent VMs; “we patch guest kernels” is not a containment story.
- Harness design — same lesson as agent harness work: isolation belongs outside the model.
Honest Limitations
- Disclosure describes Accomplish’s lab chain on their machine — your build/kernel may differ.
- “Informative” ≠ “users are safe”; it means bounty scope.
- Cloud default is a product claim — confirm session mode yourself.
- This post intentionally omits exploit steps.
- Estimated “500k Mac users” figures circulating in secondary coverage are researcher/press estimates — treat as directional exposure, not an Anthropic census.
Bottom Line
SharedRoot is less “Claude went rogue” and more “guest-root plus whole-host mount.” Kernel CVEs will keep arriving; scoped mounts and host-enforced boundaries are what make agent laptops survivable.
The uncomfortable takeaway for 2026 agent products: a polished UI and a “real VM” badge do not equal a threat model. If the host disk is one privilege escalation away, every PDF and repo you feed the agent is a potential path to your SSH directory. Prefer cloud execution, scope mounts ruthlessly, and treat local agent runtimes with the same seriousness you already apply to browser extensions and developer CLI tokens. Pair this write-up with the Cowork safety hub and the safe-use guide before you re-enable local sessions on machines that touch production. If your MDM cannot force cloud mode, treat local Cowork as an exception that needs a ticket — not a default for knowledge workers.
Related on explainx.ai
- Claude Shared Chats Indexed by Google — Privacy Fix
- GrapheneOS duress PIN — Atlanta federal prosecution
- Is Claude Cowork safe? — security hub
- How to use Claude Cowork safely
- Claude Memory Heist — web_fetch exfil
- Claude Cowork Record a Skill
- ChatGPT AgentForger — Workspace Agents
- Sakana Fugu cyber orchestration
- What is an agent harness?
- Grok Build secrets / repo upload risks
Sources: Accomplish AI — SharedRoot; Escaping the Claude Cowork sandbox (Jul 23, 2026) · CVE-2026-46331 public advisories · Anthropic Cowork product behavior as reported by researchers
Security status changes with app builds and kernel images. Re-verify Claude Desktop / Cowork release notes and your MDM policy before clearing local agents for sensitive work.
