[BUG] Cowork (Windows): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after Windows update KB5124008 (26200.9445) — uninstalling the KB fixes it

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

After the September 2026 Windows 11 cumulative security update KB5124008 (OS build 26200.9445) was installed and the machine rebooted, the Cowork local sandbox (Claude Desktop, Windows) can no longer mount any host drive share.

The VM boots, vsock RPC works, and on the host side HcsModifyComputeSystem returns hr=0x0 for every Plan9 share — but inside the guest every 9p mount fails with invalid argument. Every device_bash call then fails with:

sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

Uninstalling KB5124008 and rebooting fully restores the sandbox. Nothing else helped.

Environment

• Claude Desktop 1.49585.0 (MSIX Claude_1.49585.0.0_x64__pzs8sxrjxfjjc), CoworkVMService running, VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62, SDK 2.1.260
• Windows 11 Pro 24H2, build 10.0.26200 (→ 26200.9445 with KB5124008)
• Hyper-V (all features) + Virtual Machine Platform enabled; HypervisorPlatform disabled; VBS/HVCI running
• WSL2 (docker-desktop distro) present and still working with the KB installed (wsl -d docker-desktop ls /mnt/host/c is fine)
• Antivirus: Bitdefender + Windows Defender (unchanged before/after)
• Drives shared into the VM: C:\ plus 8 mapped SMB network drives (Q–Z), all reachable (< 0.5 s each)

Timeline (2026-09-09, local UTC+8)

What did NOT help

• Multiple full reboots
• Re-adding / changing the connected folder (a plain local NTFS folder fails exactly like the Dropbox one — not a cloud-files issue)
• Verifying all mapped network drives are reachable (they are)
• Stopping CoworkVMService, rotating the guest log, restarting
• Renaming vm_bundles\claudevm.bundle and letting Claude re-download a clean bundle (8 GB rootfs re-downloaded; same 0/9 result)

What DID help

• wusa /uninstall /kb:5124008 + reboot → sandbox works immediately, no other change.

The regression seems specific to how Cowork's 9p mount / token-based Plan9 share (flags=0x10 hasToken=true) interacts with the updated Hyper-V Plan9 server, since WSL2 drvfs kept working.

What Should Happen?

The Cowork VM should mount the host drive shares ([hyperv] mounted 9/9 Plan9 shares) and device_bash should be able to access connected folders under $HOME/mnt/<folder>, exactly as it did before KB5124008 was installed (and as it does again after uninstalling it). If a Windows Hyper-V/Plan9 update breaks the 9p handshake, Cowork should at least surface a clear error instead of VM started successfully on the host with silent 0/9 mounts in the guest.

Error Messages/Logs

### App side (%LOCALAPPDATA%\Claude\Logs\cowork_vm_node.log)
[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed (78ms)
[VM:start] Startup complete, total time: 3868ms
[vmOneShot] Running: bash [2 arg(s)] as rcw-...
[vm-stderr oneshot-] sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

### Host side (C:\ProgramData\Claude\Logs\cowork-service.log) — looks healthy
[VM] User token set for Plan9 identity
[VM] Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
[HCS] HcsModifyComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
... (same for q r s t u w y z, ports 9916-9925, all hr=0x0)
[VM] VM started successfully
[RPC] sdk-daemon connected from VM ...
[VM] Sent plan9Shares notification (9 shares)
[VM] Installed 99 CA certificates in guest
[RPC] Process oneshot-... exited: code=1 signal=<nil>

### Guest side (C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log) — freshly re-downloaded bundle, KB5124008 installed
[coworkd] detected Hyper-V host, loading vsock/9p modules
[hyperv] setting up Hyper-V socket modules
[hyperv] modules loaded successfully
[coworkd] resolved host share base: /mnt/.virtiofs-root/shared
[rpc] connecting to host CID=2 port=51234
[rpc] connected successfully
[rpc] ready event sent
[hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
[hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
[hyperv] mounting Plan9 share "q" via vsock port 9916 at /mnt/.virtiofs-root/shared/q
[hyperv] failed to mount Plan9 share "q": Plan9 mount failed: invalid argument
... (r s t u w y z identical: "Plan9 mount failed: invalid argument")
[hyperv] mounted 0/9 Plan9 shares
[coworkd] installed 99 host CA certificates
[coworkd] connected, waiting for commands

### Same guest log, before the KB (02:06 boot) / after uninstalling the KB
[hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
[hyperv] Plan9 share "c" mounted at /mnt/.virtiofs-root/shared/c
...
[hyperv] mounted 9/9 Plan9 shares

### Windows components replaced by KB5124008 (System32, written 2026-09-09 01:58-01:59)
vmcompute.exe       10.0.26100.8875
vmwp.exe            10.0.26100.8875
computestorage.dll  10.0.26100.9444
vmbusr.sys          10.0.26100.8524
p9np.dll            10.0.26100.9278
p9rdr.sys           10.0.26100.9444

### Windows Application event log (every service start, pre-existing, probably unrelated)
CoworkVMService: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access is denied.

Steps to Reproduce

1. Windows 11 Pro 24H2 (build 26200) with Hyper-V enabled, Claude Desktop 1.49585.0 with Cowork working normally (device_bash can list $HOME/mnt/<folder>).
2. Install the September 2026 cumulative security update KB5124008 (OS build 26200.9445) via Windows Update and reboot.
3. Open Claude Desktop, start a Cowork task, connect any local folder (a plain NTFS folder such as C:\Users\<you>\SomeFolder is enough — cloud-synced or not doesn't matter).
4. Run any command in the local sandbox (e.g. ls $HOME/mnt/).
   → Fails with sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared.
5. Check C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log: every share logs failed to mount Plan9 share "<x>": Plan9 mount failed: invalid argument, ending with mounted 0/9 Plan9 shares, while cowork-service.log shows all HcsModifyComputeSystem calls returning hr=0x0.
6. (Optional) Rename %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle, restart Claude so it re-downloads a clean bundle → same result.
7. Uninstall the update: wusa /uninstall /kb:5124008, reboot, start Cowork again.
   → mounted 9/9 Plan9 shares, ls $HOME/mnt/ works.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Same Claude Desktop 1.49585.0 / VM bundle 2a762adf — works on Windows build 26200 WITHOUT KB5124008; breaks with it

Claude Code Version

Claude Desktop 1.49585.0 (Windows MSIX), Cowork VM SDK 2.1.260, VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• This is Claude Desktop Cowork (the local Hyper-V sandbox), not the claude CLI itself, so the "Claude Code version" / "Terminal" fields don't map 1:1 — I filled them as best I could.
• Diagnostics were gathered with read-only PowerShell scripts (service/registry state, hcsdiag list, event logs, file versions, guest/host/app logs). Full logs are available on request; I can also reinstall KB5124008 and capture anything else you need.
• Two unrelated observations from the same session, in case they help:
  1. With the old bundle the guest console log (coworkd\user-<SID>.log) stopped being written after the first boot of the day (later boots produced a 0-byte file even after rotating it); the freshly downloaded bundle logs normally.
  2. CoworkVMService logs failed to configure SCM recovery actions ... Access is denied on every start (pre-existing).
• KB5124008 is a security update, so a Cowork-side fix (or at least a clear error message pointing at the Windows Plan9 change) would be much better than asking users to stay unpatched.