[BUG] Cowork (Windows 10 22H2): all Plan9 shares fail with "Plan9 mount failed: invalid argument" after September 2026 cumulative — 4/4 → 0/4, host reports hr=0x0

Preflight Checklist

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

What's Wrong?

Summary

Since the September 2026 cumulative updates installed on this machine, the Cowork VM boots
normally but mounts zero of four Plan9 shares. Every share fails with
Plan9 mount failed: invalid argument, including c (a plain local NTFS volume).

The host side reports complete success — all four HcsModifyComputeSystem calls return
hr=0x0 — so the failure is only visible in the guest console log. From the user's
perspective the shell reports sandbox-helper: no Plan9 drive shares mounted under
/mnt/.virtiofs-root/shared, which reads as a workspace problem rather than a mount failure.

This machine mounted 4/4 successfully on nine consecutive boots between 28 July and
8 September 2026. The first 0/4 boot follows the only change in that window: the
September cumulative, which rewrote vmcompute.exe and vmwp.exe.

This appears to be the Windows 10 22H2 counterpart of #92984, which reports the identical
error string on Windows 11 26200 and pins it to KB5124008. KB5124008 is not installed here
and is not applicable to this build.

Environment

| | |
|---|---|
| OS | Windows 10 Pro 22H2, build 19045.7725 |
| Arch | x64 |
| CPU | 13th Gen Intel Core i5-1345U |
| Claude Desktop | 1.49585.0.0 (MSIX) |
| CoworkVMService | Running (Automatic) |
| vmcompute service | Running (Manual) |
| VirtualMachinePlatform | Enabled |
| HypervisorPlatform | not present |
| Microsoft-Hyper-V-All | Disabled (role not installed; VMP only) |
| HypervisorPresent | True |
| hypervisorlaunchtype | Auto |
| Free space on C: | 43.9 GB |

Guest log — the actual failure

C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log

2026/09/10 13:15:31 [coworkd] session disk mounted successfully at /sessions
2026/09/10 13:15:31 [coworkd] user recovery complete: recovered=0 skipped=1 failed=0
2026/09/10 13:15:31 [rpc] connected successfully
2026/09/10 13:15:31 [coworkd] IPv4 route is available
2026/09/10 13:15:31 [rpc] ready event sent
2026/09/10 13:15:31 [hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
2026/09/10 13:15:31 [hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
2026/09/10 13:15:31 [hyperv] mounting Plan9 share "x" via vsock port 9923 at /mnt/.virtiofs-root/shared/x
2026/09/10 13:15:31 [hyperv] failed to mount Plan9 share "x": Plan9 mount failed: invalid argument
2026/09/10 13:15:31 [hyperv] mounting Plan9 share "y" via vsock port 9924 at /mnt/.virtiofs-root/shared/y
2026/09/10 13:15:31 [hyperv] failed to mount Plan9 share "y": Plan9 mount failed: invalid argument
2026/09/10 13:15:31 [hyperv] mounting Plan9 share "z" via vsock port 9925 at /mnt/.virtiofs-root/shared/z
2026/09/10 13:15:31 [hyperv] failed to mount Plan9 share "z": Plan9 mount failed: invalid argument
2026/09/10 13:15:31 [hyperv] mounted 0/4 Plan9 shares

Everything before the mounts is healthy: VM boots, session disk formats and mounts, vsock RPC
connects, network comes up, 101 host CA certificates install, API reachability confirmed.
c is a plain local NTFS volume and fails identically to the three mapped network drives,
so this is not drive-type specific.

Regression window

Every mounted N/N Plan9 shares line in the guest log, in order:

2026/07/28 16:29:41 [hyperv] mounted 4/4 Plan9 shares
2026/07/30 10:48:32 [hyperv] mounted 4/4 Plan9 shares
2026/08/02 20:36:17 [hyperv] mounted 4/4 Plan9 shares
2026/08/05 08:44:00 [hyperv] mounted 4/4 Plan9 shares
2026/08/07 14:41:06 [hyperv] mounted 4/4 Plan9 shares
2026/08/14 08:29:07 [hyperv] mounted 4/4 Plan9 shares
2026/09/03 09:07:32 [hyperv] mounted 4/4 Plan9 shares
2026/09/07 07:29:15 [hyperv] mounted 4/4 Plan9 shares
2026/09/08 22:12:01 [hyperv] mounted 4/4 Plan9 shares   <-- last good
2026/09/10 13:15:31 [hyperv] mounted 0/4 Plan9 shares   <-- first bad

Updates installed in that window (CBS Setup event log):

09/09/2026 00:48:39  Package KB5122877 changed to the Installed state
09/09/2026 02:27:21  Package KB5122878 changed to the Installed state
09/09/2026 02:27:21  Package KB5126421 changed to the Installed state

Hyper-V binaries rewritten during that window:

vmcompute.exe   10.0.19041.1   LastWriteTime 09/09/2026 00:55:16
vmwp.exe        10.0.19041.1   LastWriteTime 09/09/2026 00:55:17
winhvr.sys      10.0.19041.5072  LastWriteTime 14/10/2025  (unchanged)

Also worth noting on this build: p9np.dll and p9rdr.sys are not present on the
filesystem and the p9rdr service does not exist (OpenService FAILED 1060). This was also
true during the working period, so it is not itself the regression, but it may be relevant to
how the guest-side 9p client negotiates with the host on Windows 10 vs Windows 11.

Host log — reports success

C:\ProgramData\Claude\Logs\cowork-service.log

16:24:33 [VM] Starting compute system...
16:24:33 [HCS] HcsStartComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
16:24:33 [VM] Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
16:24:33 [HCS] HcsModifyComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
16:24:33 [VM] Adding Plan9 share via HcsModifyComputeSystem: name=x path=<network> port=9923 flags=0x10 hasToken=true
16:24:33 [HCS] HcsModifyComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
   ... y and z identical ...
16:24:35 [VM] Sent plan9Shares notification (4 shares)
16:24:35 [VM] Installed 101 CA certificates in guest
16:24:37 [VM] API reachability: REACHABLE

HcsGetComputeSystemProperties reports "State":"Running" throughout. There is no
host-side indication that anything failed.

Steps to reproduce

1. Windows 10 Pro 22H2 (19045.7725) with VirtualMachinePlatform enabled, Hyper-V role not installed
2. Claude Desktop 1.49585.0.0 (MSIX), Cowork working normally (4/4 shares)
3. Install the September 2026 cumulative (KB5122878 / KB5122877 / KB5126421)
4. Start a Cowork session requiring the local shell
5. Guest log shows mounted 0/4 Plan9 shares; the shell reports

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

Ruled out

| Hypothesis | Result |
|---|---|
| KB5124008 (per #92984) | Not installed — Windows 11 only, N/A to this build |
| Virtual Machine Platform disabled | Enabled |
| Insufficient disk space | 43.9 GB free |
| Corrupt/truncated rootfs.vhdx | Full 8.7 GB re-download, no change |
| Corrupt sessiondata.vhdx | Renamed and rebuilt; disk mounts fine, no change |
| Mapped network drives X/Y/Z | Same drives mounted 4/4 on 8 Sept; local c fails identically |
| OneDrive redirection | Documents\Claude is not a reparse point |
| VM failing to start | VM reaches State: Running, RPC connected, API reachable |

Suggested fixes

1. Surface guest mount failures to the host and the UI. mounted 0/4 Plan9 shares is a

fatal condition reported only in a guest log the user has no reason to know exists. The host
sees hr=0x0 and reports nothing. The UI says "sandbox down", which points at the VM rather
than at the mount. This is the single biggest cost here — the actual error was one line, and
it took hours to reach because nothing surfaced it.

1. Log the 9p mount arguments on EINVAL — msize, version, trans, aname, access flags. EINVAL

from mount(2) on 9p almost always means an option the server rejected, and the failing
option would identify the incompatibility immediately.

1. Consider whether flags=0x10 hasToken=true shares negotiate differently against the

post-September Plan9 server on the 19041 servicing branch, as #92984 suggests for 26200.

1. Make individual share failures non-fatal. c alone would be enough for most sessions;

losing all four because the set is treated atomically turns a partial failure into a total one.
(Also requested in #47570 and #44486.)

Related issues

• #92984 — identical error string, Windows 11 26200, KB5124008
• #92958 — ARM64, add_plan9_shares reports success but attaches nothing, KB5124012
• #43290 — Windows 10 Pro 22H2, Plan9 share access denied after an update
• #47570 — service attempts to mount a nonexistent drive letter
• #44486 — service crashes when a drive cannot be mounted as a Plan9 share

Diagnostic data available

Full host log, complete guest console log (104 MB, covering July–September including all nine
good boots and the bad one), Windows update history, optional-feature state, Hyper-V binary
versions and filter-driver list can be provided on request.

What Should Happen?

sandbox should be usable

Error Messages/Logs

Steps to Reproduce

1. Windows 10 Pro 22H2 (19045.7725) with VirtualMachinePlatform enabled, Hyper-V role not installed
2. Claude Desktop 1.49585.0.0 (MSIX), Cowork working normally (4/4 shares)
3. Install the September 2026 cumulative (KB5122878 / KB5122877 / KB5126421)
4. Start a Cowork session requiring the local shell
5. Guest log shows mounted 0/4 Plan9 shares; the shell reports

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

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

n/a

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_