[BUG] Cowork Plan9 mount fails (errno=22) on Release Preview 26300.9539 — despite KB5129195 fix already present in the build

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?

Cowork's Plan9 host-folder mount fails with errno=22 (EINVAL) on a Windows 11 Release Preview build that Microsoft's own catalog lists as already containing the KB5129195 fix for this exact issue. See full details and host log below.

What Should Happen?

Cowork should mount the Plan9 host-folder shares and connect the workspace to local files, as it did on this same build on 9/19

Error Messages/Logs

[VM] VM started successfully
[RPC] sdk-daemon is ready
[RPC] API reachability: "REACHABLE"
[VM] Guest could not mount Plan9 share "c" (port 9902): stage="mount" errno=22 "Plan9 mount failed: invalid argument"
[VM] Guest could not mount Plan9 share "g" (port 9906): stage="mount" errno=22 "Plan9 mount failed: invalid argument"
[VM] Guest mounted 0/2 fixed-drive Plan9 shares

Steps to Reproduce

1. Open Claude Desktop's Cowork tab on the environment described below. 2. Start any Cowork session. 3. Workspace fails to connect. Note: not deterministically reproducible from a fresh install — see timeline and ruled-out causes below, which is the actual diagnostic evidence for this report.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Claude Desktop 2.2553.1 — same app version both times; no Desktop update confirmed between working (9/19) and failing (9/21) states.

Claude Code Version

N/A — this is a Cowork/Claude Desktop bug, not Claude Code CLI. Claude Desktop version: 2.2553.1

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Follow-up to #94869 (closed), reproduced on a different, newer branch than originally reported there — this time on a build that Microsoft's own catalog confirms already carries the KB5129195 fix.

Environment:

Windows 11 Home Insider Preview (Evaluation), version 26H2
Release Preview channel (moved here from Experimental on 9/19, specifically to get onto the shared servicing branch that has the fix)
Build 26300.9539 (KB5124010, installed 9/19) — cumulative, later than 26300.9457, the revision Microsoft's Update Catalog lists as carrying KB5129195 for this exact branch

Timeline ruling out a new regression:

Cowork worked normally on this build on 9/19 (verified).
Failed again on 9/21, same exact error to the user, with zero Windows updates installed between the two dates (confirmed via Settings > Windows Update > Update history — no new entries).
Same build both times. This is not a fresh regression from a new patch.

Ruled out, in order tested:

Full system reboot (twice) — no change.
Memory Integrity / HVCI — was enabled, disabled it, rebooted, no change.
Hyper-V Administrators local group — was empty (net localgroup showed no members), added the user, rebooted, no change.
sessiondata.vhdx — present, correct size, timestamp updates on each attempt (host is reaching this step fine).

Root cause, from C:\ProgramData\Claude\Logs\cowork-service.log (host-side): VM boot, HCS compute system creation, network connect, and sdk-daemon handshake all succeed cleanly. CA certificate installation succeeds (69 certs). Then, immediately after, both fixed-drive Plan9 shares fail identically (see Error Messages/Logs above). The guest-side coworkd log never receives a new entry for the failed attempt — it's still stamped from the last successful session (9/19), confirming the failure happens on the host side of the handshake, before the guest daemon logs anything about the mount attempt itself.

Why this seems worth a closer look: the working assumption after #94869 was that Release Preview/shared-branch builds were safe once they picked up KB5129195. This shows the same errno=22 recurring on a build strictly newer than the one Microsoft's catalog lists as fixed, on the same machine, with no OS-level change between a working and a failing run. That points to either a host-side state issue that survives a full reboot, or a race/intermittent condition in how HcsModifyComputeSystem's Plan9 share gets applied — not a simple "fix hasn't shipped yet" gap.

Happy to pull anything else — full cowork-service.log, HCS config JSON (included above), or run further diagnostics on request.