[BUG] Cowork Plan9 share fails (errno=22) on Windows Server 2025

[LanceNero]

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?

On Windows Server 2025 (OS build 26100.33451, x64, nested virtualization enabled), the Cowork sandbox VM boots and connects normally, but the host-folder Plan9 share is refused by the guest with errno=22, so the workspace never gets access to local files and every bash call fails.

The app surfaces: "Claude couldn't connect your C: drive to its workspace... A Windows update released September 8 prevents Claude's workspace from reaching your files. Install the latest Windows update and restart your computer."

On Server that advice cannot be followed, and that is the point of this report. Microsoft shipped the Plan9 fix only to client SKUs. From Microsoft's own release notes for the 2026-09-14 out-of-band wave:

KB	Applies to	Fixes the Plan9 regression?
KB5129195	Windows 11 24H2 / 25H2	Yes — "[Hyper-V (known issue)] Fixed: applications that use HCS-managed virtual machines experienced issues when sharing host folder with Linux VMs using Plan9." / "Folders shared from the Windows host using Plan9 did not appear or could not be accessed in the guest environment."
KB5129235	Windows Server 2025	No — only RDS instability and 8-channel/3D USB Audio Class 1.0. No mention of Plan9, HCS, or Linux-VM folder sharing anywhere in the article.
KB5129237	Windows Server 2022	No — identical two fixes (RDS + audio). No Plan9 mention.

Worse, the Server branch's September cumulative — KB5122871 (Server 2025, OS build 26100.33438) — lists only two known issues (WSUS sync error detail, RDS instability). The Plan9 regression is not acknowledged on the Server branch at all, unlike the client branches where it is a documented known issue with a shipped fix.

The binaries match that KB exactly:

Binary	Broken Server 2025 box	Client reports (#92984 etc.)
vmcompute.dll	10.0.26100.33438	working 9278 / broken 9444
computecore.dll, computestorage.dll	10.0.26100.33438	9278

26100.33438 is precisely KB5122871's OS build. The Sept 14 OOB for Server (KB5129235) raised the OS build to .33451 but did not replace those HCS binaries — consistent with its fix list containing nothing about HCS.

I know Cowork is not an officially supported platform on Windows Server. Filing anyway because the evidence isolates a Microsoft-side gap that is invisible from the client branches, and because the in-app remedy cannot work there.

What Should Happen?

Cowork should mount the host drive share and connect the workspace to local files, as it does on the same machine configuration with a pre-September Windows build.

Two secondary expectations:

1. The startup error should not tell Server users to install a Windows update that does not exist for their SKU. If the OS SKU is readable, the message could say that no Server fix is currently available.
2. The LCU-rollback workaround circulating in the related issues should be flagged as unavailable on image-deployed machines (details in Additional Information).

Error Messages/Logs

# Host: C:\Users\<user>\AppData\Local\Claude-3p\logs\cowork_vm_node.log

[VM:steps] vm_boot completed (7727ms)
[VM:steps] add_plan9_shares started
[VM:start]  Still waiting for guest connection... 10019ms elapsed, 21 polls
[VM] Network status: CONNECTED
[VM:steps] guest_ready completed (0ms)
[VM:steps] add_plan9_shares failed (10644ms): guest refused share c from the Windows share server: errno=22 (mount)
[VM:steps] sdk_install failed (1ms): RPC error -1: host drive share "c" not mounted: guest refused share c from the Windows share server: errno=22 (mount)
[VM:start] Startup failed: Error: RPC error -1: host drive share "c" not mounted: ... errno=22 (mount)
[VM:start] Skipping auto-reinstall (host drive share "c" did not mount in the guest), leaving VM offline
Dispatching startup error: Claude couldn't connect your C: drive to its workspace, so it can't access your local files.

# Every later session repeats it on the already-connected fast path:
[startVM] VM already connected
[warn] [startVM] Post-connect setup failed on already-connected fast path: Error: RPC error -1:
       host drive share "c" not mounted: guest refused share c from the Windows share server: errno=22 (mount)

# main.log - bash tool calls then fail:
[workspaceMcpServer] bash: vmStatus=ready after 75ms wait
[workspaceMcpServer] bash resume failed: RPC error -1: failed to mount
       /mnt/.virtiofs-root/shared/c/... as outputs: source path is under Plan9 share "c" which is not mounted
[warn] [workspaceMcpServer] bash failed: bash failed on resume, create, and re-resume.

# The VM itself is healthy throughout - only the share fails:
#   vmStatus=ready, VM listed Running by `hcsdiag list`, vmwp.exe alive

Steps to Reproduce

1. Deploy Windows Server 2025 (24H2 servicing base, build 26100) x64 with nested virtualization enabled, from an image built 2026-09-09 or later — i.e. carrying KB5122871 and/or KB5129235. Confirm with:
   (Get-Item C:\Windows\System32\vmcompute.dll).VersionInfo.FileVersion → 10.0.26100.33438
2. Enable the Virtual Machine Platform feature and restart:
   dism /online /enable-feature /featurename:VirtualMachinePlatform /all
3. Install Claude Desktop, launch it, open Cowork.
4. Start any Cowork session and run any bash command.
5. Observe the startup error, and in cowork_vm_node.log: add_plan9_shares failed ... errno=22 (mount).

Control (confirms the OS build is the only variable): repeat on an image built 2026-08-12 — build 26100.33296, vmcompute.dll 26100.33296, August KBs only — with the same Claude Desktop version. The shares mount and the sandbox works.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

Not an app regression — the app version is constant and the Windows build is the variable:

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Terminal.app (macOS)

Additional Information

Environment

• Windows Server 2025 Datacenter, 24H2 servicing base, x64; OS build 26100.33451 (failing) / 26100.33296 (working)
• Cloud VM, 16 vCPU, nested virtualization enabled at the hypervisor level
• Claude Desktop 2.19675.0.0 (MSIX), Bedrock / 3P deployment
• VirtualMachinePlatform Enabled; Microsoft-Hyper-V, HypervisorPlatform and WSL all Disabled
• vmcompute, hns, nvagent all running; vfpext.sys present; CoworkVMService running
• No third-party antivirus; connected folder is plain local NTFS

The LCU rollback workaround is structurally unavailable on image-deployed machines

Several client reporters restored the sandbox by removing the September LCU. On an image-deployed machine that is not possible:

Remove-WindowsPackage -Online -NoRestart -PackageName Package_for_RollupFix~...~26100.33451.1.0
  -> 0x800f0905        (DISM /Online /Remove-Package gives the same)

CBS.log explains why:

Appl: Higher version found for package: Package_for_RollupFix~...~26100.1742.1.10, superseded.
      (Version on system: Package_for_RollupFix~...~26100.33451.1.0)
Appl: Evaluating package applicability for ...26100.1742.1.10, applicable state: Superseded
DISM: Package ...26100.1742.1.10 with CBS state 4 (CbsInstallStateStaged)

The only other LCU present is the RTM baseline, in state Staged + Superseded — it was never installed, so removing the current LCU has no previous installed LCU to revert to. There were no restore points either. This is a different failure from the 0x800f0825 "permanent package" errors others reported, and it applies to any machine deployed from an image with the LCU integrated at build time — which is most cloud VMs.

Confirmed workaround: deploy from a pre-September image

Verified end to end on this platform:

	pre-September image (2026-08-12)	September image
OS build	26100.33296	26100.33451
vmcompute.dll	26100.33296	26100.33438
installed KBs	August only	+ KB5122871 / KB5129235
Cowork Plan9 shares	mount — sandbox works	errno=22, sandbox dead

vmcompute.dll does not exist until VirtualMachinePlatform is enabled. On a pre-September image it is then installed from the local component store at that image's servicing level (.33296) — i.e. the pre-regression binary. Enabling the feature with /LimitAccess keeps DISM from pulling a newer payload from Windows Update.

Two caveats for anyone following this:

1. Block automatic updates (NoAutoUpdate=1) before first boot, or the September cumulative reinstates the regression.
2. It is a one-way door — once the machine takes the September cumulative it cannot be rolled back, for the reason above. The workaround therefore means staying one month behind on security updates until Microsoft ships a Server fix.

Ruled out on this machine

All three documented known-issue causes, plus several plausible ones:

Candidate	Why it is not the cause
Nested virtualization unsupported	VM demonstrably runs — vmStatus=ready, VM listed Running in hcsdiag list, vmwp.exe alive
Missing HCS services (HNS / vmcompute / vfpext)	All present and running
Cowork virtualization service not registered	CoworkVMService running
VirtualMachinePlatform not enabled	Enabled
WSL not enabled	Cowork does not use WSL; shares mount on the working machine with WSL disabled
"A shutdown cycle left virtualization services uninitialized"	A genuine in-OS Restart (System event 1074 reading "initiated the restart", not "power off") changed nothing
Pending servicing reboot	None pending at failure time
App regression	Same app version mounts shares fine on the pre-September image

One triage note: Win32_Processor.VMMonitorModeExtensions and SecondLevelAddressTranslationExtensions read False on this platform both with and without nested virtualization enabled at the hypervisor level. They are not a usable indicator of nested-virtualization availability here, so please don't treat them as one.

What I think should change

1. The known-issue note and the in-app message should distinguish Server SKUs, where there is no fix to install.
2. Please escalate to Microsoft: the regression is acknowledged and fixed on the client branches but is not even listed as a known issue for Server 2025 / Server 2022, whose September cumulative ships the same HCS binaries.

Happy to supply fuller logs, the complete binary version inventory for both machines, or to test a candidate build.

Related

#92958 (hub, client branches, rollback A/B on five machines) · #92984 (KB5124008 rollback restores it) · #93682 · #92985 · #94266 · #95557 and #95910 (client, fix installed but still failing — distinct from this report, where no Server fix exists to install)

[nightcinder]

Confirming on Windows Server 2025 (Hyper-V host, headless): both the Sept cumulative and the OOB build are affected, and rolling back fixes it

• OS: Windows Server 2025, build 26100
• Cowork host-folder mounts failed with the Plan9 errno=22 error after the September 2026 cumulative update. device_bash and the connected-folder shell were unusable.
• Builds tested:
  • 26100.33438 (KB5122871 cumulative): broken
  • 26100.33451 (KB5129235 out-of-band): still broken. On Windows 11 the equivalent OOB fix (KB5129195) resolved this, but the Server OOB did not.
• Fix: I removed both September packages (33451, then 33438) with Remove-WindowsPackage, newest first, and went back to the August build (26100.33296, confirmed via UBR). After that the workspace status reported fixed and the shell worked again.
• Hyper-V and VirtualMachinePlatform were enabled and HypervisorPlatform was disabled. That is unchanged by the rollback, so it doesn't look like a feature-configuration problem.
• Workaround: roll back to 26100.33296 and pause updates, otherwise Windows Update will reinstall the cumulative.

Happy to supply DISM /Online /Get-Packages output or logs if useful.