Cowork (Windows): VM cannot mount host C: drive after Windows cumulative update - 'Plan9 mount failed: invalid argument'

Status Open

Reported on v2.1.260

Maintainer reply None cached

Activity 0 comments · opened Sep 11, 2026

Summary

On Windows, the Cowork sandbox VM can no longer mount the host C: drive. Every mcp__workspace__bash call fails, and VM startup itself now fails outright:

RPC error -1: host drive share "c" not mounted: Plan9 mount failed: invalid argument

This started immediately after a Windows cumulative-update reboot. It survives app restarts, a full machine reboot, and two desktop app updates.

Unrelated to #91582 (that was a permission regression, fixed in 1.44121.2). This is a mount failure with a different signature.

Environment

Windows 11 Pro 10.0.26200 (x64)
Claude desktop 1.52386.0.0, MSIX / Microsoft Store install. Also reproduced on 1.49585.0.0.
Bundled Claude Code 2.1.260
Cowork session type: hostLoopMode: true
Windows updates installed immediately before onset: KB5126052, KB5124008, KB5124007

Timeline

Bash worked normally for days, then stopped at the Windows update reboot and has not worked since.

2026-09-10 08:26:01  [workspaceMcpServer] bash done: exit=0        <-- last success ever
2026-09-10 09:04:25  TrustedInstaller initiated restart of computer   (Windows Update)
2026-09-10 09:05:07  system back up
2026-09-10 09:05:12  Package KB5126052 successfully changed to the Installed state
2026-09-10 09:05:13  Package KB5124008 successfully changed to the Installed state
2026-09-10 09:21:07  [VM:start] Beginning startup      <-- first VM boot after the update
2026-09-10 09:21:14  [VM:steps] add_plan9_shares completed (7ms)
2026-09-10 09:21:19  [VM:start] Startup complete, total time: 12722ms
2026-09-10 09:23:31  first mount failure

KB5124007 had reached Installed at 06:25:08 pending that reboot, so all three took effect at 09:04.

Daily workspaceMcpServer outcomes:

| Date | bash done | bash failed |
|---|---|---|
| 2026-09-08 | 232 | 1 |
| 2026-09-09 | 119 | 1 |
| 2026-09-10 | 29 | 33 |
| 2026-09-11 | 0 | 2 |

All 29 successes on 09-10 are before 08:26. Every attempt after the update reboot has failed.

Error detail

Per-call failure (seen 2026-09-10 onward). All three recovery paths fail — resume on the mount, create on a stale sandbox user, then re-resume:

[workspaceMcpServer] bash: vmStatus=ready after 7ms wait, cmdLen=7, vmCwd=/sessions/<name>/mnt/<folder>,
    mounts=<folder>,uploads,.claude/skills,.claude/projects,outputs,.local-plugins/...

[workspaceMcpServer] bash resume failed, retrying with create:
    RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Local/Packages/
    Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/<account>/<org>/
    local_<session>/outputs as outputs:
    source path .../outputs is under Plan9 share "c" which is not mounted

[workspaceMcpServer] bash create failed
    (RPC error -1: ensure user: user <name> already exists unexpectedly: uid=1523 gid=1523),
    retrying resume

[workspaceMcpServer] bash failed: bash failed on resume, create, and re-resume.

VM startup failure (from 2026-09-11). The host reports the share step succeeding, then the guest rejects the mount:

2026-09-11 01:56:39 [VM:steps] add_plan9_shares completed (11ms)
2026-09-11 01:56:44 [VM] Network status: CONNECTED
2026-09-11 01:56:45 [VM:steps] sdk_install started
2026-09-11 01:56:48 [VM:start] Startup failed:
    RPC error -1: host drive share "c" not mounted: Plan9 mount failed: invalid argument
2026-09-11 01:56:48 [VM:start] Skipping auto-reinstall (host drive share "c" did not mount in the guest),
    leaving VM offline
2026-09-11 01:56:48 Dispatching startup error: Claude couldn't connect your C: drive to its workspace,
    so it can't access your local files. Reinstalling won't fix this. Your chats and files are safe.

Every subsequent attempt logs:

[startVM] Post-connect setup failed on already-connected fast path:
    RPC error -1: host drive share "c" not mounted: Plan9 mount failed: invalid argument

Eight of these on 2026-09-11, latest at 18:06:53. The VM has not come up healthy once that day.

invalid argument suggests the guest kernel is rejecting the 9p mount parameters outright, rather than the share being absent — the host-side add_plan9_shares step reports success every time.

What does not fix it

App restart — no effect.
Full machine reboot (2026-09-10 21:41:07). VM booted clean at 21:44:47 with add_plan9_shares completed (10ms) and Startup complete; bash still failed at 21:45:59 with the same mount error.
App updates. Broken on 1.49585.0.0, still broken after the update to 1.52386.0.0.
Reinstalling — the app's own error path says so and skips auto-reinstall.

The host side looks healthy throughout: CoworkVMService is Running, \\.\pipe\cowork-vm-service and the daemon console pipe both exist, VM network status CONNECTED, API reachability REACHABLE.

Secondary issue

The create fallback cannot rescue the failure because it trips on a stale sandbox user:

ensure user: user <name> already exists unexpectedly: uid=1523 gid=1523

Worth handling independently — even once the mount is fixed, a wedged user leaves resume/create/re-resume with no working path. I have an isolated occurrence of this same already exists unexpectedly error from 2026-08-31, on a day when mounts were otherwise fine.

Impact

No shell in Cowork at all, so no running scripts and no reading or writing binary Office files (the Read tool refuses them, and the shell was the only route). Scheduled tasks that shell out fail.

Expected

The Cowork VM mounts the host C: drive after a Windows cumulative update, or — if the mount genuinely cannot be established — the app surfaces an actionable remedy rather than a state that survives every restart path.

I have not tried removing the Windows updates to confirm causation; happy to test that if it would help narrow it down.

View original on GitHub ↗