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

Confirming this on a second x64 machine.

Config: Windows 11 x64, Claude Desktop 1.49585.0.0, Hyper-V + Virtual Machine
Platform enabled. Broke immediately after the 2026-09-09 update batch
(KB5124008, KB5124007, KB5126052). Worked normally until 2026-09-08 23:21 UTC;
first failure 2026-09-09 10:37 UTC, on the first attempt after the reboot.

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

Additional data points from ~4 hours of narrowing it down:

• The host side reports the folders as connected the whole time:

get_device_info keeps listing them, and device_list_dir /
device_stage_files / device_commit_files keep working perfectly. Only the
guest mount is missing. So file access is a poor signal that things are fine.

• WSL2 is unaffected: wsl echo ok boots a VM and answers.
• Not path-related: a freshly granted folder with no spaces or accents

(C:\Users\<user>\Downloads) also fails to mount. All connected folders fail,
not just one.

• Ruled out with tests: virtualization (Hyper-V + VMP on, WSL2 works),

Windows Hypervisor Platform (enabling it changed nothing), Defender's
Controlled Folder Access (off), app reinstall, and a brand-new task with a
fresh VM.

• Renaming %APPDATA%\Claude to force a clean bundle made it worse, not better:

the environment then fails earlier with "Workspace unavailable / failed to
start", matching the secondary defect described in #92958. Restoring the
folder is needed to get back to the mount-failure state.

Impact: the local shell is the only way to run tests or git in a connected
folder, so a full working day was lost. Writing files still works, which makes
this look like a partial outage rather than a full one.

Confirming this on a second machine, same symptom and same build.

Environment: Windows 11 Pro 25H2, build 26200.9445, x64. KB5124007, KB5124008, KB5126052 all installed 2026-09-09. Claude desktop 1.49585.0 (MSIX), Electron 44.2.0, Node 24.20.0.

Same error, same file versions you reported — p9rdr.sys at 10.0.26100.9444 (written 09-08 22:54:16) alongside p9np.dll and computecore.dll still at 10.0.26100.9278.

One extra data point: a VM boot that isolates the reboot from the app update

Both changes landed here overnight, but a VM boot fell between them, which separates the two candidate causes:

| Time (local) | Event |
|---|---|
| 09-08 22:40:34 | Last working shell. App 1.46388.4, VM booted 09-07. |
| 09-08 22:53–22:54 | LCU writes p9rdr.sys / vmcompute.dll / hvix64.exe → 9444. Not yet active. |
| 09-09 00:25:10 | App auto-updates 1.46388.4 → 1.49585.0 (deferred MSIX registration). |
| 09-09 00:25:30 | VM boots on the new app + new smol-bin.x64.vhdx — and mounts successfully. |
| 09-09 00:32:45 | Machine reboots; KB5124007/8 and KB5126052 finalised. |
| 09-09 08:42 onward | Every boot since fails. |

The successful mount on the new app build:

2026/09/09 04:25:30 [hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
2026/09/09 04:25:30 [hyperv] Plan9 share "c" mounted at /mnt/.virtiofs-root/shared/c
2026/09/09 04:25:30 [hyperv] mounted 1/1 Plan9 shares

So it is not the app update, and it is not the LCU's file-copy step either — it is specifically the reboot that activates the new driver and hypervisor images. That further supports your conclusion that 1.49585.0 is not implicated.

Host succeeds, guest never mounts

Identical on all four failing boots:

10:35:45 [VM]  Plan9 share added: c -> C:\ (port=9902, readOnly=false)
10:35:49 [HCS] HcsModifyComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
10:36:05 [VM]  Sent plan9Shares notification (1 shares)

Then every device_bash call returns exit 1 with zero stdout — a command whose first statement was echo HOME=$HOME, touching no mounted path, printed nothing. So sandbox-helper aborts before the shell starts.

Worth flagging for anyone triaging from host logs: the mounts=<name>:rw token in [remote-bash] lines comes from the app's own grant bookkeeping and is not evidence the guest holds a share. It reads identically on working and broken boots.

Counts

703 successful shells across 18 VM boots before the reboot. 10 attempts across 4 boots after it, zero successes. Also ruled out here: folder re-attachment, app restarts, and a clean manual reboot this morning (10:34:21) — the fresh VM at 10:35:41 failed the same way.

One correction to a theory I see floated on similar reports: this is not a startup race. getDefaultWorkspaceFolders returns 0 folders on 22 of 22 VM boots ever recorded here, 18 of which then ran 703 clean shells.

Offer

I have not uninstalled the KB, so this machine is still in the broken state and I have the full log set — main.log, cowork_vm_node.log, cowork-service.log and the guest coworkd log. Since rolling back fixes it, the original reporter's machine presumably can no longer reproduce. Happy to run diagnostics or pull specific logs if that would help.

I can independently confirm this regression.

• Claude Desktop: 1.49585.0
• Windows 11 Pro 25H2: build 26200.9445
• Updates installed: KB5124008 and KB5126052
• Virtual Machine Platform: enabled
• Firmware virtualization and the Windows hypervisor: active
• CoworkVMService, vmcompute, and HNS: operating normally
• Symptom began after the Windows update and reboot
• Cowork’s VM starts, but shell execution remains unavailable
• Rebooting, fully quitting Claude, and restarting the relevant services did not resolve it

The host-side Claude service log reports that the VM started successfully and that the Plan9 share was added, consistent with the behavior described in this issue. I have not uninstalled KB5124008.

UPDATE: uninstalling KB5124008 + reboot resolves this. See comment below.

Confirming #92984 on Windows 11 Pro x64 (not just ARM64), OS build 26200.

Timeline:

• 2026-09-08: Cowork sandbox working normally all day, hundreds of bash

calls against a mounted host folder.

• 2026-09-09: KB5124008, KB5124007 (SSU) and KB5126052 (.NET) installed.
• 2026-09-09 onward: every shell call fails. No host share mounts.

Error (two distinct failures each time):

resume: RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/
<user>/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/...
as outputs: source path ... is under Plan9 share "c" which is not mounted;
create: RPC error -1: ensure user: user <name> already exists unexpectedly:
uid=1183 gid=1183

Two observations that may help narrow it:

1. The mount target in the error VARIES between attempts (outputs on some,

.auto-memory on others). It is not one folder failing — no path under
C: can mount, consistent with the share never being attached.

1. The create fallback also fails, because the stale VM user blocks a clean

rebuild. So the automatic recovery path is broken too, which is why
quitting and relaunching the app never helps.

Ruled out on this machine:

• C: is a local fixed NTFS volume, healthy, ~40GB free.
• No reparse points anywhere in either mount chain. Checked

%USERPROFILE%, AppData, AppData\Local, and the Claude package folder —
all Reparse: False. (One unrelated junction exists elsewhere in the
user profile, outside both mount paths.)

• AppData is not redirected — resolves literally, no OneDrive involvement.
• Full app quit with Task Manager confirmed clear: no change.
• Reboot: no change.

So this is not folder layout, drive type, redirection or a stale app process.
Matches the KB5124008 correlation in this issue exactly.

------------

Confirmed fixed by uninstalling KB5124008.

A/B on the same machine; nothing else changed:

| | KB5124008 installed | KB5124008 removed |
|---|---|---|
| Plan9 shares | none mount | all mount |
| bash / code execution | fails every call | works |
| host folder visible in VM | no | yes |

Steps that resolved it:

1. wusa /uninstall /kb:5124008 (elevated)
2. Reboot
3. Cowork sandbox came up normally on next launch — shares mounted, shell

working, host folder readable and writable.

Windows 11 Pro x64, 26200.9445 with KB5124008 → 26200.9278 after uninstalling. Left KB5124007 (SSU) and KB5126052 (.NET)
installed — removing KB5124008 alone was sufficient, so those two appear
uninvolved.

Two notes for anyone else hitting this:

• Pause Windows Update immediately after the uninstall. Otherwise KB5124008

may reinstall on its own within a day and the sandbox could break again, with no
obvious reason why.

• This workaround has a real cost. KB5124008 is the September Patch Tuesday

update and patches two actively exploited elevation-of-privilege
vulnerabilities. Staying on the workaround means staying unpatched against
those, which is not a reasonable long-term position on a machine holding
confidential work. I'd rather reinstall the update than keep the workaround,
so a fix on the Cowork side would be genuinely valuable.

Independently confirmed on two machines.

| | Desktop | Laptop | Laptop after rollback |
|----------------|-----------------|-------------|-------------------------|
| OS build | 26200.9445 | 26200.9445 | 26200.9278 |
| Architecture | x64 (i7-12700) | x64 | x64 |
| KB5124008 | installed | installed | removed |
| Claude Desktop | 1.49585.0.0 | 1.49585.0.0 | 1.49585.0.0 (unchanged) |
| device_bash | fails | fails | works |

Same error text as yours. Removed KB5124008 from the laptop with the app
version held constant — UBR 9445 -> 9278 and the shell came back immediately.
Matches your A/B in both directions.

Cross-link worth having: #92958 is the same regression on the other branch.
It reports this identical failure on ARM64 / 26H1, triggered by KB5124012
(build 28000.2954) — the same September 2026 Patch Tuesday, also confirmed by
rollback. Neither issue currently references the other. So this isn't one KB on
one branch: both variants of the September cumulative carry it, and the two are
probably worth tracking together.

One correction that may save triage time — #92958 cites
add_plan9_shares completed (4-12ms) as the signature of the silent failure.
It isn't diagnostic: my logs show 0ms, 5ms, 8ms, 12ms and once 98ms on days
when everything worked fine. That step logs completed identically whether or
not it attaches anything. Your [hyperv] mounted 0/9 Plan9 shares is the line
that actually distinguishes the two states.

None of the following help on a patched machine (all tested here):

• Reboots, including cold boots; CBS/WU reboot-pending both False
• Shutting down other hypervisors (a work VM on the desktop; the laptop has none)
• Add-AppxPackage -Register from the manifest
• Disconnecting or recreating connected folders — note the failing share is

"c", i.e. the app's own session directories, not the user's folder at all

• Hyper-V features — VirtualMachinePlatform and all Microsoft-Hyper-V-*

Enabled, and the VM itself boots normally in ~73ms

Partial workaround while unpatched: the desktop bridge is unaffected —
device_list_dir, device_stage_files and device_commit_files all keep
working. Files can be staged into the cloud container, processed there, and
committed back, which covers much of what the local shell was doing. Slower and
more token-expensive, but it keeps work moving without rolling back a security
cumulative on a work machine.

+1 on your closing point. A host-side hr=0x0 alongside 0/9 mounts in the
guest cost me most of a day chasing folders, drives, chat state and app
registration — because the only tool that could have diagnosed the sandbox was
the shell that wouldn't start.

Confirming this on Windows 11 24H2 — same KB, different servicing branch, so the regression is broader than the title suggests. Rollback also isolates which of the updated files is responsible.

Environment

• Windows 11 24H2, 10.0.26100 UBR 9445 — KB5124008, Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26, PackageState: Installed, ReleaseType: SecurityUpdate
• x64 (AMD64), not ARM
• Claude Desktop MSIX Claude_pzs8sxrjxfjjc, Cowork SDK 2.1.260
• Single Plan9 share (C:\ only) — no mapped network drives, no cloud-synced folders
• Update history records KB5124008 installed 2026-09-08 17:50; the replaced binaries have LastWriteTime 2026-09-08 13:19–13:20. First failures 2026-09-09.

KB5124008 shipped to both branches: 26200.9445 for the OP, 26100.9445 here. Not 25H2-specific.

Same failure

Host side (C:\ProgramData\Claude\Logs\cowork-service.log) — reports success on every boot:

[VM] User token set for Plan9 identity
[VM] Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
[HCS] Calling HcsModifyComputeSystem (config len=152)
[HCS] HcsModifyComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
[VM] VM started successfully
[RPC] sdk-daemon connected from VM ...
[VM] Sent plan9Shares notification (1 shares)
[RPC] API reachability: REACHABLE

Guest side (C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log), same boot:

[coworkd] resolved host share base: /mnt/.virtiofs-root/shared
[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] mounted 0/1 Plan9 shares

Also worth noting the HCS create config contains "Plan9": {} — the share is attached post-boot via HcsModifyComputeSystem, which is presumably why the host-side call can succeed while the guest mount fails independently.

User-facing symptoms

For anyone searching, this surfaces as a cascade of unrelated-looking errors, none of which mention Plan9:

RPC error -1: SDK version 2.1.260 not verified at /mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/claude-code-vm/2.1.260/.verified

failed to mount .../outputs as outputs: source path ... is under Plan9 share "c" which is not mounted

create: ensure user: user <session-name> already exists unexpectedly

The third is downstream: every session is force-terminated, so the session users it created persist in sessiondata.vhdx and the next attempt collides with them. Deleting sessiondata.vhdx clears that error but does not fix the mount.

Rollback confirms the cause, and narrows it

Removed the rollup and rebooted:

Remove-WindowsPackage -Online -PackageName "Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26"

Result: UBR 9445 → 9168, p9rdr.sys 9444 → 8972, p9np.dll 9278 → 8972. Cowork works immediately — the host log now ends with Process oneshot-... exited: code=0 instead of code=1, and commands execute in the sandbox. No other change.

File versions, broken state on this machine vs the OP's:

| File | This machine (26100) | OP (26200) | After rollback here |
| -------------------- | -------------------- | --------------- | ------------------- |
| p9rdr.sys | 10.0.26100.9444 | 10.0.26100.9444 | 10.0.26100.8972 |
| p9np.dll | 10.0.26100.9278 | 10.0.26100.9278 | 10.0.26100.8972 |
| computestorage.dll | 10.0.26100.9444 | 10.0.26100.9444 | — |
| vmbusr.sys | 10.0.26100.8524 | 10.0.26100.8524 | — |
| vmcompute.exe | 10.0.26100.8457 | 10.0.26100.8875 | 10.0.26100.8457 |
| vmwp.exe | 10.0.26100.8457 | 10.0.26100.8875 | 10.0.26100.8457 |

Two things follow:

1. vmcompute.exe and vmwp.exe differ between two machines with identical symptoms (8457 here, 8875 for the OP), so neither is the regression.
2. Those same two files are unchanged across the broken and working states on this machine — only the p9 components moved during the rollback. That points squarely at p9rdr.sys / p9np.dll rather than the VM worker, computestorage.dll, or vmbusr.sys.

Since KB5124008 replaced all six files at once, a single-machine report can't separate them; this A/B does.

Two secondary observations

1. The guest console log stops being written after the first boot of the day — confirming the OP's observation, but it is not a symptom of this bug. coworkd\user-<SID>.log still had a LastWriteTime of 10:03 while the service was booting VMs at 10:40 and 11:21, including the working post-rollback boot. The file goes stale rather than empty, so Get-Content -Wait silently shows pre-reboot content. This actively obstructs diagnosis and looks like a separate defect worth its own issue.
2. Reproduces with a single share and no network drives, so it is unrelated to share count, SMB, or cloud-files providers.

Possibly the same regression

#92958 (Windows ARM64, host reports success, mounted 0/N in guest, attributed to KB5124012) looks like this same regression on the ARM branch rather than a distinct bug — same shape, same SDK 2.1.260, same VM bundle 2a762adf, with KB5124012 presumably the ARM equivalent of KB5124008.

Agreed with the OP that a Cowork-side fix, or failing that a clear error surfaced from mounted 0/N instead of VM started successfully, would be much better than asking people to remove a security update.

Confirming the same failure on another Windows 11 Pro 25H2 x64 installation:

• Windows build: 26200.9445
• Claude Desktop: 1.49585.0.0
• Cowork SDK: 2.1.260
• KB5124008 installed September 9

Host-side share attachment reports success, but the guest records:

[hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
[hyperv] mounted 0/1 Plan9 shares
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

This affects multiple Cowork sessions. Six connected folders all depend on the single C: share. File listing, staging and committing remain functional; shell execution fails.

Verified locally:

• VirtualMachinePlatform is enabled (Win32_OptionalFeature.InstallState=1).
• vmcompute, hns and CoworkVMService are running.
• HypervisorPresent is true.
• The failure persisted after an actual Windows restart, confirmed by the restart event and subsequent Kernel-Boot event with BootType=0.

Causation limit: KB5124008 reached Installed state at 06:26:52Z, and Claude first launched its updated version at 06:30:56Z. The first recorded guest mount failure was 07:03:47Z. Both updates preceded the failure, so my local timeline does not isolate which change triggered it.

I have not rolled back KB5124008 or reset/deleted the VM. A human support request is queued, and relevant host/guest log excerpts are available for private sharing. A supported fix that preserves the Windows security update would be appreciated.

I faced this issue too after a Windows update of KB5124008. One of my CoWork chats failed with "RPC error -1: failed to mount.... is under Plan9 share "c" which is not mounted", tried everything including the Claude helper but it did not work.
then on a Claude-Chat (Fable 5.1, Max), it recommended uninstalling KB5124008. i have done so (via Powershell in admin mode), and the chat is working fine.
I have uploaded the diagnosis.md file from my PC to review.

diagnosis_public.md

UPDATE — A/B rollback confirmed on x64 (this is not just a symptom match):

KB5124008 installed -> "no Plan9 drive shares mounted", every boot, 100% repro
KB5124008 uninstalled + reboot -> shares mount, device_bash works immediately

Claude Desktop held constant at 1.49585.0 across both states; bundle
2a762adfc2eea13eca0d113a2e6452ff00ae3f62, SDK 2.1.260 unchanged.
Windows build was the only variable.

This matches #92958 (KB5124012 / ARM64) — same silent-failure shape on a
different architecture and a different KB, so the regression is in the shared
Windows Plan9/HCS path, not architecture-specific.

Confirming on a second, independent x64 machine — same build, same app, same bundle.

Windows 10.0.26200.9445 (KB5124008 installed 2026-09-09 11:23 local)
Claude 1.49585.0 MSIX | bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 | SDK 2.1.260

Regression boundary from cowork_vm_node.log, exact to the second:
09-05 .. 09-09 10:41 1518 vmOneShot bash runs, zero share warnings
09-09 11:14:04 MoUsoCoreWorker.exe forces restart for KB5124008
(app log: "Windows session ending (close-app, critical)" —
the only "critical" in 4 days of logs)
09-09 12:47:44 first bash run after the update ->
"sandbox-helper: no Plan9 drive shares mounted"
since then fails on every boot: 10+ VM boots, 3 machine reboots,
4 distinct rcw- sessions

Also ruled out here, independently of the KB:

• Reset-AppxPackage (full LocalCache wipe; app then re-downloaded rootfs.vhdx +

vmlinuz + initrd from scratch, download_and_sdk_prepare 93179ms vs 13ms cached,
and ran its own deleteVMBundle auto-reinstall) -> still fails identically

• CoworkVMService PathName resolves to the matching app version
• WSL2 ls /mnt/c works fine
• VirtualMachinePlatform Enabled

+1 on the reporter's point: add_plan9_shares logging "completed (3ms)" while
attaching zero shares is what makes this take hours to diagnose.

Another x64 confirmation, with one configuration not covered above: this is a
remote Claude session linked to the desktop app, not a locally started Cowork
task. Same failure.

• Windows 11 x64, build 26200.9445 (KB5124008 installed)
• Claude Desktop 1.49585.0, Electron 44.2.0, Node 24.20.0
• Shares are 4 local fixed NTFS volumes — no SMB or mapped network drives involved

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

device_list_dir, device_stage_files and device_commit_files keep working
normally throughout, so the session looks healthy from the outside and only the
shell is dead.

Not uninstalling the KB here, so this machine stays in the broken state if any
diagnostics would help.

Confirming this on x64, including the rollback.

Host: Windows 11, build 26200.9445
KBs: KB5124007, KB5124008, KB5126052 installed 2026-09-08 23:43 – 09-09 00:34
App: Claude Desktop 1.49585.0 (Claude_1.49585.0.0_x64__pzs8sxrjxfjjc, SignatureKind Developer)
Sandbox: Hyper-V (vmcompute → vmwp → vmmem), WSL not installed

Broken exactly as described: every device_bash call returned
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
with app-log entries rejecting paths as
... is under Plan9 share "c" which is not mounted

FIX CONFIRMED. Uninstalled KB5124008, rebooted:
p9rdr.sys 10.0.26100.9444 → 10.0.26100.8972
All connected folders mounted immediately and device_bash works again. This is the
first x64 confirmation of the rollback fix — #92958 has it on ARM64.

Ruling out the app version, since the timing invites that theory: the MSIX package
staged 09-08 14:42 but did not first launch until 09-09 00:25:11, i.e. after
KB5124008 was in, so the new build never ran on a pre-KB system. A clean uninstall
and reinstall of the identical 1.49585.0 reproduced the fault exactly. The app
version was never the variable.

One log-reading trap that cost me hours: add_plan9_shares logs "completed" with a
duration unconditionally, and the duration is not diagnostic. On this host:

09-08 08:43:06 0 ms → mounted everything, worked all day
09-09 00:25:20 207 ms → mounted nothing
09-09 08:25:45 59 ms → mounted nothing
09-09 11:29:29 0 ms → mounted nothing
09-09 11:45:13 210 ms → mounted nothing
09-09 11:51:04 24 ms → mounted nothing

A 0 ms run succeeded and a 210 ms run failed. The host-side line cannot tell you
whether shares attached; the only signal is the downstream failure.

Also tried before the rollback, none of which helped: three full reboots, removing
and re-adding connected folders, mapping a second drive letter to the same network
share and connecting that instead, and a full uninstall/reinstall of the MSIX package.

Note KB5124008 is cumulative, so October's cumulative will presumably carry the same
p9rdr.sys and reintroduce this. Windows Update is paused here as a stopgap.

Independent confirmation on Windows 11 Home 25H2 (x64), A/B completed: KB5124008 breaks the share, uninstalling it restores the sandbox

Same failure, same fix, on a machine with no Hyper-V role and no WSL (Home edition, Virtual Machine Platform only), so the regression is in the inbox HCS Plan9 path itself. Claude Desktop build and VM bundle were held constant throughout.

Controlled result (app 1.49585.0.0, bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62, SDK 2.1.260)

| Windows build | KB5124008 | Cowork bash |
|---|---|---|
| 26200.9168 (before the KB was activated) | staged, not active | WORKS — 27/27 calls (scheduled tasks, 00:37–01:36) |
| 26200.9445 | installed | FAILS — 33/33 calls across 8 VM boots, incl. a freshly re-downloaded bundle |
| 26200.9168 (wusa /uninstall /kb:5124008 + reboot) | removed | WORKS — first call exit=0, connected folder listed, write + read-back OK, python3/git run |

Rows 1 and 3 are the same OS build; row 2 differs only in the KB. The app updated 1.46388.4.0 → 1.49585.0.0 before row 1, so the app update is not the variable.

Environment

• Claude Desktop 1.49585.0.0 (MSIX Claude_1.49585.0.0_x64__pzs8sxrjxfjjc), CoworkVMService running, VM bundle 2a762adf…, SDK 2.1.260
• Windows 11 Home 25H2, x64; Virtual Machine Platform enabled; Hyper-V role not available on Home; HypervisorPlatform disabled; WSL not installed; Windows Defender only
• Shares into the VM: C:\ plus 5 mapped SMB drives (V–Z) to a NAS that was unreachable during the tests
• Cowork had worked daily on this machine since May 2026

Timeline (local UTC+2)

| Time | Event |
|---|---|
| 2026-09-08 20:58 | Windows Update staged the KB5124008 binaries (reboot pending) |
| 2026-09-08 21:31 | Claude Desktop auto-updated to 1.49585.0.0; VM booted on the new app at 21:42 |
| 2026-09-09 00:37–01:36 | Scheduled Cowork tasks: every bash call bash done: exit=0 |
| 03:31–03:39 | App quit for the update reboot; three TrustedInstaller.exe reboots; KB5124008 + KB5126052 reach Installed state at 03:39:50 |
| 06:49 / 06:54 | First VM boot after the KB / first bash call fails: … is under Plan9 share "c" which is not mounted, then ensure user: user <session-name> already exists unexpectedly on the create retry |
| 06:49–17:45 | 8 boots (5 OS restarts, MSIX Repair, service restart, fresh bundle): identical |
| 17:44 | First boot of a freshly re-downloaded bundle: guest mounted 0/1 Plan9 shares |
| ~19:55 | wusa /uninstall /kb:5124008, reboot → build 26200.9168 |
| 20:02 | First bash call after the reboot: bash done: exit=0; 20:10 functional check passed |

What did NOT help

• 5 full OS restarts; Settings → Apps → Claude → Repair (package re-registered fine)
• Quitting/relaunching the app; restarting CoworkVMService
• Moving vm_bundles\claudevm.bundle away and letting the app re-download the bundle (1.2 GB compressed → 8 GB rootfs, new sessiondata.vhdx, fresh smol-bin.vhdx): first boot of the fresh image fails identically

What DID help

• wusa /uninstall /kb:5124008 + reboot. Nothing else changed. Windows Update paused afterwards.

Error Messages/Logs

### App side (%LOCALAPPDATA%\Claude\Logs\main.log) — first failure after the KB, 06:54
[workspaceMcpServer] bash: vmStatus=ready after 58ms wait, cmdLen=576, vmCwd=/sessions/<session-name>/mnt/<folder>, mounts=<folder>,uploads,.claude/skills,.claude/projects,outputs,...
[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 ... is under Plan9 share "c" which is not mounted
[workspaceMcpServer] bash create failed (RPC error -1: ensure user: user <session-name> already exists unexpectedly: uid=1645 gid=1645), retrying resume
[workspaceMcpServer] bash failed: bash failed on resume, create, and re-resume. resume: RPC error -1: failed to mount ...

### Same log, last working call on the SAME app build, 01:36 (KB staged, not yet active)
[workspaceMcpServer] bash done: exit=0, duration=513ms, outputBytes=20

### Same log, first call after uninstalling the KB, 20:02
[workspaceMcpServer] bash done: exit=0, duration=1779ms, outputBytes=61

### Host side (C:\ProgramData\Claude\Logs\cowork-service.log) — identical on working (09-06, 09-09 20:02) and broken boots
[VM] User token set for Plan9 identity
[VM] Plan9 share added: c -> C:\ (port=9902, readOnly=false)
[HCS] HcsCreateComputeSystem returned: hr=0x0 ...
[HCS] HcsStartComputeSystem returned: hr=0x0 ...
[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.
[VM] VM started successfully
[VM] Sent plan9Shares notification (1 shares)
# HcsCreateComputeSystem config JSON byte-identical across all of these boots.

### Guest side (C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log) — fresh bundle, KB installed (UTC)
2026/09/09 15:45:30 [hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
2026/09/09 15:45:30 [hyperv] mounted 0/1 Plan9 shares

### Same guest log, last healthy boot before the KB (2026-09-05, UTC)
[coworkd] detected Hyper-V host, loading vsock/9p modules
[hyperv] modules loaded successfully
[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 1/1 Plan9 shares
[coworkd] SDK source on 9p mount, negotiated msize=262144, copy buffer=262120

### System32 versions, with KB5124008 -> after uninstall
vmcompute.dll       10.0.26100.9444 -> 10.0.26100.9168
computestorage.dll  10.0.26100.9444 -> 10.0.26100.8972
p9rdr.sys           10.0.26100.9444 -> 10.0.26100.8972
vmfirmwarehcl.dll   10.0.26100.9444
computecore.dll     10.0.26100.9278
p9np.dll            10.0.26100.9278
hvsocket.sys        10.0.26100.8972 (unchanged by the KB)

Additional Information

• Microsoft's WSL 2.9.11 pre-release notes (2026-09-09) describe HCS-managed Plan9 shares failing to attach after recent Windows updates and work around it with WSL's per-user Plan9 server, with a Microsoft root-cause fix "in progress". Cowork uses the inbox HCS path directly, which is consistent with what is observed here.
• Diagnostics were gathered read-only from service/registry/event logs, file versions and the app/host/guest logs. Full logs available on request.
• Three related observations from the same logs:

1. Unreachable mapped network drives eat the boot timeout. The disconnected SMB drives are added as optional Plan9 shares after c: v fails with HRESULT 0x80370118 after ~8 s, w with 0x80070035 after 12–55 s, x/y/z are skipped when the 20 s aggregate budget is exhausted. Whenever that step exceeded the app's 60 s startVM timeout (3 of 8 boots), the app logged VM boot failed: Request timed out: startVM and left the VM "offline" although the service logged VM started successfully seconds later; the app reconnected on the next request. Adding local shares first, or not charging network-share failures against the boot timeout, would avoid this.
2. CoworkVMService terminated unexpectedly (exit code 1067, SCM event 7034) ~25 s after the VM was force-stopped on app quit. Because failed to configure SCM recovery actions ... Access is denied is logged at every start, it stayed down until a manual elevated Start-Service; the app reported VM service not running. The service failed to start. Second occurrence on this machine.
3. Guest console capture starts too late to catch the mount. Starting daemon console reader is logged only after add_plan9_shares completes, so when that step is slow (see 1) the guest's boot lines, including the mounting Plan9 share "c" attempt, are lost. With the old bundle no guest console output was captured at all for the boots between 09-06 and 09-09 despite Connected to daemon console pipe. Starting the reader before the share loop would make this failure diagnosable from the host.

Related: #92958 (ARM64, KB5124012 / 28000.2954).

Independent confirmation on x64, with a clean A/B.

Environment

• Windows 11 x64, build 10.0.26200.9445 (KB5124008, installed 2026-09-09)
• Claude Desktop 1.49585.0 / Electron 44.2.0 / Node 24.20.0
• 5 connected folders, all OneDrive-synced

Symptom. Every device_bash call fails before executing anything:
All 5 folders report failed to mount. device_list_dir, device_stage_files and
device_commit_files are completely unaffected — only the in-VM shell is dead.

Did not help: quitting from the system tray 3×, two normal reboots, one hard reboot.

Fix. Uninstalled KB5124008 from the Windows Update settings screen, rebooted:

| Build | device_bash |
|---|---|
| 10.0.26200.9445 (KB5124008) | dead — no shares mount |
| 10.0.26200.9168 (rolled back) | all 5 folders mount, read + write OK |

Claude Desktop version unchanged across both. Working immediately after the reboot,
no other action needed.

Gotcha for anyone else hitting this: Windows Update history still lists KB5124008
after a successful removal, which looks like the uninstall failed. It didn't — check
cmd /c ver for the build number instead.

Confirming on a second x64 machine. Same build, same VM bundle, with a seven-week
guest-log history that makes the transition sharp.

Environment

• Windows 11 Pro 25H2, OS Build 26200.9445
• Claude Desktop 1.49585.0 (MSIX, x64) — log reports windowsStore=true
• VM SDK 2.1.260
• VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 (identical to OP)

Guest log: forty healthy boots, then zero

From %ProgramData%\Claude\Logs\coworkd\user-<SID>.log, one line per VM boot:

2026/07/20 15:38:47 [hyperv] mounted 4/4 Plan9 shares
... 38 further boots, every one 4/4 or 4/5 ...
2026/09/05 04:26:23 [hyperv] mounted 4/5 Plan9 shares
2026/09/08 20:55:00 [hyperv] mounted 0/4 Plan9 shares

Forty consecutive boots over seven weeks mounted four or more shares. The first
boot after the 09-08 restart mounted zero. No intermediate degradation.

The failing boot in full:

2026/09/08 20:55:00 [hyperv] setting up Hyper-V socket modules
2026/09/08 20:55:00 [hyperv] modules loaded successfully
2026/09/08 20:55:00 [hyperv] found session disk at /dev/sdc
2026/09/08 20:55:00 [hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
2026/09/08 20:55:00 [hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
2026/09/08 20:55:00 [hyperv] mounting Plan9 share "d" via vsock port 9903 at /mnt/.virtiofs-root/shared/d
2026/09/08 20:55:00 [hyperv] failed to mount Plan9 share "d": Plan9 mount failed: invalid argument
2026/09/08 20:55:00 [hyperv] mounting Plan9 share "e" via vsock port 9904 at /mnt/.virtiofs-root/shared/e
2026/09/08 20:55:00 [hyperv] failed to mount Plan9 share "e": Plan9 mount failed: invalid argument
2026/09/08 20:55:00 [hyperv] mounting Plan9 share "f" via vsock port 9905 at /mnt/.virtiofs-root/shared/f
2026/09/08 20:55:00 [hyperv] failed to mount Plan9 share "f": Plan9 mount failed: invalid argument
2026/09/08 20:55:00 [hyperv] mounted 0/4 Plan9 shares

Byte-identical error string to OP's. Module load and session-disk detection both
succeed; only the mounts fail.

One distinction worth drawing. The recurring 4/5 above is share "g"
failing with Plan9 mount failed: **file exists** on roughly half of all boots
going back to July. That is a separate, longstanding, harmless condition.
invalid argument appears exactly once in seven weeks: the first boot after the
restart. The two should not be conflated when reading these logs.

The restart, and an honest caveat about what it isolates

2026-09-08 13:40:04 [updater] Staged version 1.49585.0 is still current
2026-09-08 14:38:00 still running Claude_1.46388.4.0_x64
2026-09-08 14:42:59 last successful bash (app log)
2026-09-08 14:49:38 Event 1074 - MoNotificationUx.exe initiated restart
(Windows Update prompt)
2026-09-08 14:51:46 Event 6005 - boot
2026-09-08 14:53:00 Event 1074 - TrustedInstaller.exe initiated restart
(second install phase), NT AUTHORITY\SYSTEM
2026-09-08 14:53:30 Event 6005 - boot
2026-09-08 14:54:50 now running Claude_1.49585.0.0_x64
2026-09-08 20:55:00 first VM boot after: mounted 0/4

Two things changed at that restart, and this machine cannot separate them.
KB5124008 installed, and a staged Claude Desktop MSIX update applied itself on
the same reboot (1.46388.4.0 -> 1.49585.0.0). There was no VM boot between the
two, so I have no tiebreaker. Anyone reading my boot history should treat it as
"something in the 09-08 restart broke it," not as isolation to the KB.

What does isolate it is OP's rollback: KB5124008 removed, Claude Desktop left at
1.49585.0, 9/9 shares restored. That exonerates the app version, and my machine
is then consistent with it.

Same caveat on the patch side:

KB5124008 2026-09-08
KB5124007 2026-09-08
KB5126052 2026-09-08 (.NET Framework 3.5/4.8.1 cumulative)
KB5123304 2026-08-11

Three updates on 09-08. KB5126052 is a .NET Framework cumulative and is not a
plausible cause; I have not characterized KB5124007. (Get-HotFix reports
InstalledOn as date-only with a zeroed time, so its 12:00 AM is not a real
timestamp — the Event Log times above are the real ones.)

Host side reports success on every boot

[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed (15ms)

6-15 ms across boots. No HRESULT, no warning, no retry — while the guest mounts
zero.

Other guest-side strings

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

RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/<user>/
AppData/Roaming/Claude/local-agent-mode-sessions/<...>/outputs as outputs:
source path <...> is under Plan9 share "c" which is not mounted

create: RPC error -1: ensure user: user <session> already exists
unexpectedly: uid=1121 gid=1121

Possible link to #92958

That third string is verbatim from the ARM64 issue, and the shape here is
"host reports success, guest attaches nothing" rather than the explicit HRESULT
failures in the older x64 Plan9 reports (#43290, #43896, #32828). Different KB
per architecture — 5124008 x64, 5124012 ARM64 — but possibly one root cause.
Might be worth linking the two.

Scope

• 687 bash invocations between 2026-08-21 and 2026-09-08 with zero

failures; 8 of 8 failed on 2026-09-09.

• Affects local Cowork sessions and remote/bridge sessions equally. Worth

noting because the local-session failure surfaces only in main.log; the VM
log shows the invocation with no error, so it is easy to misread as
remote-only.

• A bare echo test fails identically to a command touching a mounted folder,

so sandbox-helper aborts at startup rather than on a missing path.

• Directory listing, file staging and file commit are unaffected and worked

normally throughout. Only the in-VM shell is dead.

Two notes for anyone else collecting logs on 1.49585.0

The app log directory moved to %LOCALAPPDATA%\Claude\Logs\ (capital L, and
not under Packages\ despite the MSIX install). The commonly cited
%APPDATA%\Claude\logs\ path froze at the MSIX migration and still holds stale
files with plausible names, which reads as "logging is broken" unless you check
timestamps.

Guest logs may be unobtainable while affected. Neither cowork-service.log
nor the coworkd guest log has been written since the update went in; their
last writes are both 2026-09-08. If those reach the host through the very shares
that stopped mounting, users cannot produce guest logs while in this state,
and the history above is only recoverable because it predates the break. Worth
knowing before asking someone in this state for guest output.

Have not attempted the KB uninstall.

Confirming on Windows 11 x64, Claude Desktop 1.49585.0 — same error verbatim:

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

Virtual Machine Platform is Enabled, and both vmcompute and hns report Running:

FeatureName     : VirtualMachinePlatform
State           : Enabled

Status   Name        DisplayName
------   ----        -----------
Running  hns         Host Network Service
Running  vmcompute   Hyper-V Host Compute Service

Two additional data points beyond the original report:

1. A full OS reboot does not help. Shares fail identically after a clean restart.
2. It is not a stale share attachment. I connected a folder before the reboot (Downloads) and a brand-new one after (Documents). Both fail together — mnt/Downloads, mnt/Documents failed to mount — so a share attached seconds earlier behaves exactly like one carried across the reboot.

Scope: the failure is limited to the sandbox share layer. The same files remain fully reachable through device_list_dir, device_stage_files and device_commit_files — device_list_dir on C:\Users\johnh\Documents returns correct entries, and committing files works. Only device_bash is affected, which matches the host-reports-success / guest-mounts-zero split described above.

Another data point, on a Windows edition not yet covered here.

Same failure after KB5124008. Every shell call in Cowork fails with:

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

Environment:

• Windows 11 Home Single Language, x64, version 25H2, OS build 26200.9445
• KB5124008, installed 2026-09-09
• Lenovo Yoga Slim 7 14IMH9, Intel Core Ultra 5 125H, 16 GB RAM
• Connected folder: a plain local NTFS folder under C:\Users\<user>\, not cloud synced
• Claude Max plan

Guest log (C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log) ends with:

2026/09/09 11:06:16 [hyperv] mounted 0/2 Plan9 shares

Note the share count: 0 of 2 here versus 0 of 9 in the original report. It is
not one problematic share, it is every share regardless of how many are
configured.

What still works: reading and writing individual files through the desktop
bridge, so the session is not entirely dead. What is gone: every shell
command, which means no mv, no rm, no running a script, and no grep across
the folder tree. For a project that depends on a file integrity script and
on archiving previous versions, that removes the mechanical verification
step entirely.

I have not attempted the KB rollback. KB5124008 is a security update and I
would rather stay patched, so I cannot contribute an A/B confirmation. I can
provide additional logs if useful.

Adding Home Single Language on x64 to the affected list suggests this is
neither Pro-specific nor ARM64-specific.

Confirming on Windows 11 ARM64, Claude Desktop 1.49585.0.0 (MSIX arm64), OS Build [your build from Step 1], with KB5124008 installed: mounted 0/9 Plan9 shares, and every device_bash call fails with sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared. The host side returns hr=0x0 for every share, so the failure is silent. Uninstalling KB5124008 restores 9/9 immediately. This breaks daily production automation — I've had to remove a security update containing an actively-exploited CVE in order to keep running. Happy to provide logs or test a fix build.

Confirming this exact issue on a separate machine — same root cause, same fix, plus one new data point: it also affects the 26H2 branch, which isn't listed on Microsoft's own support page for this update.

Environment

Windows 11 Pro, version 26H2, build 26300.9445 (KB5124008 installed)
Claude Desktop 1.49585.0
Cowork VM bundle: 2a762adfc2eea13eca0d113a2e6452ff00ae3f62
VM SDK: 2.1.260

Symptom — identical to the reports above:

Guest (coworkd) log: Plan9 mount failed: invalid argument for every configured share, mounted 0/N Plan9 shares
Host (cowork-service.log): HcsModifyComputeSystem returns hr=0x0 for the same shares — looks successful on the Windows side
App surfaces this downstream as RPC error -1: SDK version 2.1.260 not verified at /mnt/.virtiofs-root/shared/...
Reproduces even with just the C: drive present (not just when several are requested together)
Not fixed by: deleting and re-downloading the VM bundle from scratch, multiple app/computer restarts

New data point: 26H2 is affected too
Microsoft's KB5124008 support page only documents builds 26200.9445 (25H2) and 26100.9445 (24H2). This machine is on 26H2 and hit the identical failure at build 26300.9445 — same UBR, different base build, so the same underlying Plan9-server change appears to have shipped across all three branches in this monthly update.

Confirmed fix
Uninstalled the update and rebooted:

Before: Version 26H2, OS Build 26300.9445
After: Version 26H2, OS Build 26300.9278
Cowork VM confirmed working immediately after: shares mount, and both shell execution and host file access through the mount verified working.

Given this now spans three Windows 11 branches with an identical error signature and an identical fix, it'd help to know whether this is being tracked as a Cowork-side compatibility fix or reported upstream to Microsoft as a regression — happy to provide further logs if useful.

Confirming #92984 on an additional machine.

Windows 11 Enterprise, build 26200.9445 (UBR 9445, from
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion).
Installed 2026-09-09: KB5124007, KB5124008, KB5126052.

Every mcp__workspace__bash call fails immediately. Two failures reported
together -- note the second, which I don't see in the original report:

resume: RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/
<user>/AppData/Local/Packages/Claude_<id>/LocalCache/Roaming/Claude/
local-agent-mode-sessions/.../outputs as outputs: source path ... is under
Plan9 share "c" which is not mounted;
create: RPC error -1: ensure user: user <workspace-name> already exists
unexpectedly: uid=1038 gid=1038

So resume fails on the unmounted share AND the create path fails on leftover
guest state, meaning it can neither reattach nor cleanly rebuild. It cycles
"attempt N of 5 since last success" and never succeeds once.

Scope:

• File tools (Read/Write/Edit/Glob/Grep) are entirely unaffected -- only the

shell is dead.

• Persists across a full PC reboot.
• Persists across new conversations. The workspace name is stable between

them, which may be why the stale guest user comes back.

• Newly connecting a folder mid-session rebuilds no mounts; bash still fails

identically.

• KB5124008 not uninstalled: it's a Patch Tuesday security update on a

domain-managed machine, so rollback isn't an option here.

Independent reproduction — capabilities reported supported despite shell failure

I can reproduce this on:

• Claude Desktop 1.49585.0.0
• Windows 11 25H2, build 26200.9445
• VirtualMachinePlatform: Enabled
• vmcompute: Running
• hns: Running

I fully exited Claude Desktop, including its tray/background process, reopened it, created a brand-new Cowork session, and connected a local project folder. The failure reproduced immediately.

Even device_bash: echo ok fails before command execution:

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

Cowork also reports that the connected folder failed to mount into the shell, while remaining reachable through device_list_dir, device_stage_files, and device_commit_files, showing the same file-access vs shell-execution split.

Two additional observations from this reproduction:

• supported-features-info.json reports the relevant Cowork/local-session capabilities as supported despite this failure.
• A separate Claude Chat session using the connected filesystem verified that three output files produced through the Cowork workflow were present on the Windows disk. Local file access remained readable/writable while device_bash failed.

I have not rolled back Windows updates, reinstalled Claude Desktop or the filesystem connector, or changed virtualization configuration. This corroborates the failure symptoms; I have not independently confirmed the underlying root cause.

Confirming on a second machine (Windows 11, domain-joined, SDK 2.1.260, Get-HotFix shows KB5124008 / KB5124007 / KB5126052 installed 9/9/2026; worked through 9/7, failed from the first session on 9/9). Same sandbox-helper: no Plan9 drive shares mounted text. Two details that may help:

1. The share failure surfaces under two other error texts depending on boot step, so people may not recognize it as this bug: RPC error -1: SDK version 2.1.260 not verified at /mnt/.virtiofs-root/shared/c/.../claude-code-vm/2.1.260/.verified — that file exists on the host (64 bytes, next to .payload and the claude binary); the guest simply can't read C:. And ... is under Plan9 share "c" which is not mounted; create: RPC error -1: ensure user: user <session-name> already exists unexpectedly — where the colliding user is the current session's own name, left behind by the first failed create.

1. Managed machines can't take the uninstall workaround. This one has Windows Update policy NoAutoUpdate=1 with patches pushed by an MSP; wusa /uninstall /kb:5124008 would be re-applied on the next cycle. Same null result as the OP from app restart, full reboot and "reinstall the workspace" (bundle rebuilt from scratch — VM boots, vmmem/vmwp/cowork-svc alive, HvHost and vmcompute running, only the host share missing). For this class of machine a Cowork-side fix is the only path. Cloud-mode sessions work fine meanwhile.

Same failure here, and I can add one data point: this is not recoverable by uninstalling the KB on a clean 25H2 image.

Environment

• Windows 11 Pro 25H2, build 10.0.26200.9445 (KB5124008 installed 2026-09-09)
• Claude Desktop 1.49585.0 (MSIX, Claude_pzs8sxrjxfjjc)
• VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62, Cowork SDK 2.1.260
• Intel NUC12SNKi72, Hyper-V + VirtualMachinePlatform enabled, VBS/HVCI running, Defender only, no WSL
• Reproduced on three clean Windows installs on a new NVMe, including one with the old data drive offline. Same result every time, because a fresh 25H2 image pulls this CU before Claude is ever installed.

Host side (cowork-service.log): the VM boots, HCS accepts the shares, and the service reports success:

[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.
[VM] VM started successfully
[RPC] sdk-daemon is ready
[VM] Sent plan9Shares notification (1 shares)

Guest side (coworkd console log): every 9p mount fails with EINVAL, C: included:

[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] mounted 0/2 Plan9 shares

App side (cowork_vm_node.log):

[VM:steps] add_plan9_shares completed (3ms)
[postConnect] Installing SDK: subpath=c/Users/<user>/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/claude-code-vm, version=2.1.260
[error] [VM:start] Startup failed: Error: RPC error -1: SDK version 2.1.260 not verified at /mnt/.virtiofs-root/shared/c/.../claude-code-vm/2.1.260/.verified

The .verified file exists on the host; the guest just cannot see the share. Then device_bash returns sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared.

Why the workaround in this thread does not apply to fresh installs: wusa /uninstall /kb:5124008 fails with 0x800f0825, and DISM shows why:

Package Identity : Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26
Description      : Fix for KB5124008
PackageFormat    : PSFX
PSFXDeltaFormat  : ForwardOnly

ForwardOnly means there is no reverse differential, so the LCU cannot be removed at all on a 25H2 install that shipped with it. Anyone on current media is stuck until the share code is fixed or Microsoft ships a follow-up CU.

Happy to run a debug build or pull more logs if it helps.

Independent confirmation, x64, same environment down to the bundle hash.

Claude Desktop 1.49585.0, MSIX Claude_1.49585.0.0_x64__pzs8sxrjxfjjc, Cowork VM SDK 2.1.260,
VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62. Windows 11 build 26200, Hyper-V and
Virtual Machine Platform enabled. Sydney.

Same guest error on every shell call:
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

Same host-side silence. Every boot logs add_plan9_shares completed (9-16ms) with no error,
and the guest then sees nothing. File tools (list, stage, commit) keep working throughout, so
only the guest's view of the shares is affected.

Clean A/B on the app version, from my own logs, which may help rule the app update in or out:

09 Sep 07:04 app binaries updated to 1.49585.0
09 Sep 08:31 VM boots normally, add_plan9_shares completes, sdk_install succeeds over
the share, no errors follow
(Windows update and restart during the day)
09 Sep 19:44 first mount failure, identical boot sequence to 08:31

The app version is unchanged across the working and failing boots, which is consistent with
this issue's KB attribution rather than the app-update attribution in #92977 and #92985.

Also tried and did not help: full quit and relaunch, wsl --shutdown / --update, four machine
restarts, Store app repair, installer re-run over the top, renaming claudevm.bundle to force a
full VM rebuild (which correctly re-downloaded rootfs.vhdx and then could not start
CoworkVMService), and starting CoworkVMService manually from an elevated prompt. The service
starts, the VM boots, and the shares are still absent.

Worth flagging one secondary defect. When the VM service failed to start, the app logged
"Skipping auto-reinstall (Windows VM service is not running; a computer restart restores it),
leaving VM offline". A restart did not restore it. The app declines its own repair path on an
assumption that is false in this state, which turned a diagnosis into several hours.

Confirming on two separately-managed machines — same KB, same failure, same fix.

Environment (both machines)

• Claude Desktop 1.49585.0.0, MSIX Claude_1.49585.0.0_x64__pzs8sxrjxfjjc, VM SDK 2.1.260
• Windows 11 Pro 10.0.26200.9445
• x64, not ARM64
• Both connected folders are OneDrive-synced — consistent with your finding that cloud vs.

local makes no difference

Both machines worked normally on 2026-09-08 and both failed on 2026-09-09. Uninstalling
KB5124008 and rebooting restored the sandbox on both.

---

The timing is not what patch day would suggest, and this is the part worth adding.

The update does not break anything when it downloads or stages. It breaks when the reboot
finalizes it. Both machines staged late on 9/8 and only reached the Installed state after
midnight, and the failure tracks Installed — not Staged.

Laptop — staged 11:45 PM on 9/8, Installed 5:29 AM on 9/9:

TimeCreated          Id Message
-----------          -- -------
9/9/2026 4:17:13 PM   2 Package KB5124008 was successfully changed to the Absent state.
9/9/2026 4:12:12 PM   7 Windows update "Security Update for Microsoft Windows (KB5124008)" was successfully uninstal...
9/9/2026 4:12:12 PM  10 This computer will restart to finish uninstalling Windows update "Security Update for Micros...
9/9/2026 4:11:36 PM   9 Windows update "Security Update for Microsoft Windows (KB5124008)" requires a computer resta...
9/9/2026 4:11:36 PM   4 A reboot is necessary before package KB5124008 can be changed to the Absent state.
9/9/2026 4:10:13 PM   1 Initiating changes for package KB5124008. Current state is Installed. Target state is Absent...
9/9/2026 5:29:27 AM   2 Package KB5124008 was successfully changed to the Installed state.
9/9/2026 12:27:09 AM  4 A reboot is necessary before package KB5124008 can be changed to the Installed state.
9/9/2026 12:03:42 AM  1 Initiating changes for package KB5124008. Current state is Staged. Target state is Installed...
9/9/2026 12:02:17 AM  2 Package KB5124008 was successfully changed to the Staged state.
9/8/2026 11:45:57 PM  1 Initiating changes for package KB5124008. Current state is Absent. Target state is Staged. C...

Desktop — staged 11:55 PM on 9/8, Installed 12:32 AM on 9/9:

TimeCreated          Id Message
-----------          -- -------
9/9/2026 4:15:36 PM   2 Package KB5124008 was successfully changed to the Absent state.
9/9/2026 4:13:22 PM   7 Windows update "Security Update for Microsoft Windows (KB5124008)" was successfully uninstal...
9/9/2026 4:13:22 PM  10 This computer will restart to finish uninstalling Windows update "Security Update for Micros...
9/9/2026 4:11:51 PM   9 Windows update "Security Update for Microsoft Windows (KB5124008)" requires a computer resta...
9/9/2026 4:11:51 PM   4 A reboot is necessary before package KB5124008 can be changed to the Absent state.
9/9/2026 4:10:39 PM   1 Initiating changes for package KB5124008. Current state is Installed. Target state is Absent...
9/9/2026 12:32:46 AM  2 Package KB5124008 was successfully changed to the Installed state.
9/8/2026 11:58:45 PM  4 A reboot is necessary before package KB5124008 can be changed to the Installed state.
9/8/2026 11:56:54 PM  1 Initiating changes for package KB5124008. Current state is Staged. Target state is Installed...
9/8/2026 11:56:47 PM  2 Package KB5124008 was successfully changed to the Staged state.
9/8/2026 11:55:19 PM  1 Initiating changes for package KB5124008. Current state is Absent. Target state is Staged. C...

The laptop is the clearest case: the package sat downloaded and staged for nearly six
hours, the sandbox was used normally during that window on 9/8, and it failed on every
attempt after the 5:29 AM transition to Installed.

So anyone with the update downloaded but not yet rebooted is still working, and will break
at their next restart rather than at a moment that lines up with patch day. Worth flagging
for triage, because it makes the bug look inconsistent across reporters when it isn't.

Get-HotFix -Id KB5124008 will not distinguish those two states, and its InstalledOn
field is date-only — on the desktop it reported 9/9/2026 12:00:00 AM against an actual
transition at 12:32 AM, and it would have reported the same for the laptop's 5:29 AM. The
Setup log is the reliable source:

Get-WinEvent -LogName Setup |
  Where-Object { $_.Message -like "*5124008*" } |
  Select-Object -First 15 TimeCreated, ID, Message

---

A different surfaced error, same underlying 0/N mount state.

The desktop never produced sandbox-helper: no Plan9 drive shares mounted. Every bash
call failed with:

resume: RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/.../uploads as uploads:
source path ... is under Plan9 share "c" which is not mounted;
create: RPC error -1: ensure user: user <generated-name> already exists unexpectedly: uid=2769 gid=2769

Two things in that worth separating. The resume failure is your bug. The create
fallback then fails for its own reason — guest state from the failed resume isn't torn
down before the retry. That looks like a distinct defect that only becomes visible once
the share failure puts the VM in this state, and it would survive a fix to the 9p handshake.

Remedies that did not help, matching yours: full app quit and relaunch, full reboot,
workspace reinstall (the app's own dialog states reinstalling won't help), and an app
reinstall over the top — which produced the same 1.49585.0.0 build, so it cannot replace
the Windows-side components at fault.

---

Post-fix verification. Both machines: sandbox starts, uname -sr returns
Linux 6.8.0-136-generic, and the connected folder mounts and lists normally.

The laptop went further, so this isn't just "it seems fine":

• uname -srm → Linux 6.8.0-136-generic x86_64
• Full tree walk of 37,279 files — no 9p/FUSE errors, no stale handles
• Write/read integrity: 5 MB file written and checksummed, mid-file seek+overwrite, 200

small files, deep nested paths, names with spaces, &, parentheses, and non-ASCII —
all correct on read-back

• The mount presents as fuse, and dmesg shows no 9p or FUSE warnings

n=2 on the cause, n=2 on the fix.

---

Standing question for the Anthropic side. KB5124008 is a security update and will be
re-offered. Is the plan to handle the new Plan9 components host-side, or is holding the
patch the expected posture until a Cowork-side fix ships? Uninstalling a security update
isn't something I want to keep doing on a schedule.

Confirming this on x64 with an identical environment.

• Windows 11 Pro 24H2, build 10.0.26200
• KB5124008 installed 2026-09-09 (Get-HotFix confirms, InstalledBy NT AUTHORITY\SYSTEM)
• Claude Desktop Cowork, Hyper-V sandbox

Symptom matches: every device_bash call fails at mount time before any
command runs. Error surfaced to the client is the downstream form —

failed to mount <path> as outputs: source path <path> is under
Plan9 share "c" which is not mounted

Two details that may be additive to the original report:

1. It broke MID-SESSION. The sandbox was working normally for several

hours of active use, then began failing after the update applied.
Not a cold-boot failure.

1. The create path reports a stale VM identity rather than provisioning

a clean one:

create: RPC error -1: ensure user: user <vm-name> already exists
unexpectedly: uid=1038 gid=1038

So after resume fails, the fallback create also fails because the
previous sandbox user still exists. This may be why restarts don't
recover it — the wedged instance isn't torn down.

Not yet attempted: wusa /uninstall /kb:5124008. Will report back if
it resolves.

What did NOT help: full Windows restart (x2), Claude Desktop restart.

Confirming on x64, and adding one data point I have not seen in this thread:
silent file-write reversions while the mount is in the degraded state.

Environment

• Windows 11 Pro 25H2, build 10.0.26200.9445 — KB5124008 installed 2026-09-09
• Claude Desktop 1.49585.0 (Cowork), Chile
• Connected folder is plain local NTFS (no OneDrive/Dropbox sync)

Symptom matches: every device_bash call fails with
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared,
while the file-bridge tools (list/stage/commit) keep working. Broke MID-SESSION
on 2026-09-09 (second report of this, matching the staged→Installed timing noted
above). Not recovered by app restart, full PC reboot, or fresh sessions — every
new session starts broken.

The new data point — possible data loss: with the mount in this state,
four separate file writes through the file-bridge (device_commit_files) returned
"written", and seconds to minutes later the file on disk was back to its
PREVIOUS content WITH A FRESH MTIME. A retry of the same write always stuck.
Only observed while the Plan9 mount was down (same machine had zero such
reversions before 09-09). If the dying mount is restoring cached copies over
fresh writes, this bug can silently discard user data even though the
file-bridge appears healthy — worth factoring into severity/triage.

Happy to provide logs.

Same failure on x64, Windows 11 25H2 build 26200.9445, Claude 1.49585.0 (MSIX). Shell in every Cowork session: sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared. The KB5124008 workaround does NOT hold here: wusa /uninstall /kb:5124008 → "required by your computer and cannot be uninstalled"; DISM /Online /Remove-Package on Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26 → 0x800f0825 (permanent); System Restore to the pre-update point "succeeded" but left the KB installed and reverted the VM bundle, after which the VM cannot start at all: sdk_install fails with SDK version 2.1.260 not verified at /mnt/.virtiofs-root/shared/c/.../claude-code-vm/2.1.260/.verified even though that file exists on the Windows side — the guest cannot read the Plan9 share. Hyper-V services (vmcompute/HvHost/vmms) running. Updates paused. Nothing left to try on the machine side.

Confirming this on a second, independent x64 machine, with a clean before/after date.

Environment

• Windows 11 25H2, OS build 26200.9445
• KB5124008 installed 2026-09-08
• Previous quality update: KB5121003 (26200.9168), installed 2026-08-11
• Claude Desktop 1.49585.0, Electron 44.2.0, Node 24.20.0
• Hyper-V enabled; no competing hypervisor

Symptom
Every device_bash call fails immediately with:

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

Timeline
Sessions on 2026-09-07 and earlier had a working shell. KB5124008 installed
2026-09-08. Every session on 2026-09-09 has failed, in three different
projects, with the identical error. The failure does not heal within a
session: a retest 8 hours after the first failure in the same session
returned the same error.

Scope
Five connected folders, all on local NTFS paths under a OneDrive-synced
directory on C:. All five fail to mount identically. No mapped network
drives involved, which matches the report above that this is not
cloud-files-specific.

What still works
device_list_dir, device_stage_files and device_commit_files all work
normally throughout, so file reads and writes continue via upload/download
while shell and code execution are unavailable. This makes the failure easy
to miss: a session can run for hours in a degraded mode and only surface it
when something downstream breaks.

Not yet attempted
I have not uninstalled KB5124008, since it is a security update. Happy to
run the A/B rollback if that would add anything beyond the confirmation
already posted, or to pull specific logs.

Cross-reference: #92958 reports the same guest-side error on ARM64 from
KB5124012, which suggests one upstream Plan9 change shipped to both
architectures.

One more confirmation, and two details I did not see upthread.

Windows 11 Pro 25H2, build 26200.9445. KB5124008 / KB5124007 / KB5126052 installed 2026-09-09, reboot applying them 02:35. Claude Desktop 1.49585.0.0, SDK 2.1.260, bundle 2a762adf.... Hyper-V binaries replaced 2026-09-08 22:49-22:50: p9rdr.sys 10.0.26100.9444, p9np.dll 10.0.26100.9278, computestorage.dll 10.0.26100.9444.

WSL is not installed on this machine at all. Several reports upthread note that WSL2 keeps working, which leaves open the question of whether a WSL component is somehow involved. Here there is no WSL to be involved, and Cowork fails identically. That removes it as a variable rather than only as a suspect.

Clean before and after, with a gap and no sessions in between:

2026-09-04 20:55:27  [hyperv] Plan9 share "c" mounted at /mnt/.virtiofs-root/shared/c   <- last success
   (no VM sessions at all between these two lines)
2026-09-09 11:26:19  [hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
2026-09-09 11:26:19  [hyperv] mounted 0/1 Plan9 shares

The first VM session after the reboot that applied the update is also the first failure. Only one share is configured here (c -> C:\), so it is not a multi-share or drive-letter interaction.

Stopping the service, killing cowork-svc.exe and letting a completely fresh VM be built (new HCS config at 2026-09-10 00:05:56, shares re-added, hr=0x0 throughout) still fails on the first bash 26 seconds later. The host and app sides both report success the whole time: add_plan9_shares completed (5147ms), Startup complete, total time: 19262ms.

Second detail, unrelated to the bug but it cost me hours of diagnosis. On 2026-08-21 at 01:11:28, during a stealth update, this installation moved its per-user log directory from %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs to %LOCALAPPDATA%\Claude\logs. Every file in the new directory carries that timestamp to the second. The old files were abandoned mid-stream, the last line in the old main.log being beforeQuitForUpdate handler fired, going down for update. Anyone following older instructions pointing at the package path will find logs that stopped weeks ago and conclude that logging is broken. A one-line marker written into the abandoned file would prevent that.

Second independent x64 confirmation, on a different machine, with matching identifiers.

Environment

| Item | Value |
|---|---|
| Host | Lenovo ThinkPad T480, x64 |
| Windows | 11 Pro, 25H2, build 26200.9445 |
| Claude desktop | 1.49585.0.0, MSIX package Claude_pzs8sxrjxfjjc |
| Cowork VM SDK | 2.1.260 |
| VM bundle | 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 |
| Connected folder | a normal local NTFS path under C:\Users\<me>\Documents |

Note: this machine reports 25H2 while the original report lists 24H2, but the build number is identical at 26200.9445.

Timeline

• 2026-09-07 20:39:08, last confirmed working bash call.
• 2026-09-08, three updates installed: KB5124008, KB5124007, KB5126052.
• 2026-09-08 17:24, app auto-updated 1.46388.4.0 to 1.49585.0.0. The app was opened but no bash call was made, so this boot proves nothing either way.
• 2026-09-09 08:29:38, first observed failure. Every bash call has failed since.

Errors

Initially:

resume: RPC error -1: failed to mount .../outputs as outputs:
source path ... is under Plan9 share "c" which is not mounted

After a full VM bundle rebuild, and still current:

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

What did not help here

Everything in the original report, plus two more:

1. A clean uninstall and reinstall of the Claude desktop app. No change. Worth noting that reinstalling delivers the same 1.49585.0.0 build, so this clears app state but does not test the app version.
2. Disabling and re-enabling Hyper-V and Virtual Machine Platform, with reboots on both sides of the cycle. No change. Consistent with the diagnosis, since re-registering the features does not revert the updated binaries.

Also confirmed, matching the original report: repeated reboots, reconnecting the folder, and a full VM bundle rename and re-download all changed nothing. The bundle hash had been identical across three app versions, so that was a genuine reset.

Additional evidence that the guest cannot read the share at all

The guest reported SDK version 2.1.260 not verified at /mnt/.virtiofs-root/shared/c/.../claude-code-vm/2.1.260/.verified, while that exact file was verified present on the host: .verified (64 bytes), .payload (103 bytes), .sdk-version (7 bytes) and the ~21MB claude binary. So the "SDK not verified" error is a downstream symptom of the missing mount, not an independent cause. Anyone hitting this should not go clear that cache.

WSL2 as a control test

WSL2 with Ubuntu was installed here and wsl -d Ubuntu -e ls /mnt/c/Users/<me>/Documents works normally. This is consistent with the original report's finding that the regression is specific to Cowork's tokenized Plan9 shares rather than to Windows guest file sharing in general, since WSL uses drvfs.

Virtualization stack looks healthy

vmcompute (Running, Manual) and vmms (Running, Automatic) are both up. Every Hyper-V event in the System log across the failure window is Information level, zero Warnings, zero Errors. The host side genuinely believes it succeeded.

Secondary bug, probably worth its own issue

When resume fails, the harness falls back to create, which then aborts:

create: RPC error -1: ensure user: user <session-name> already exists unexpectedly: uid=NNNN gid=NNNN

That turns a recoverable failure into a permanent one. resume cannot work because the share is missing, and create cannot work because resume already created the Linux user. Making create idempotent about the uid/gid, or tearing the user down first, would at least let the session retry cleanly.

Not rolling back the KB here

KB5124008 is a security rollup and this is a primary work machine, so I am leaving it installed and using the cloud path for the affected workflow instead. Flagging that because the only documented fix right now requires users to choose between a patched machine and a working product, and a second confirmation on a second architecture suggests this is worth an app-side fix rather than a KB removal recommendation.

Confirming this on x64 / Windows 11 25H2 — same failure, same cause.

Environment

• Windows 11 Pro, 25H2, OS Build 26200.9445
• Trigger: KB5124008 (2026-09 cumulative) force-installed on shutdown 8–9 Sep
• Claude desktop app: broke on 1.46388.4, and STILL broken after it auto-updated

to 1.49585.0 — so the app update does not fix it

• Architecture: x64 (not ARM)

Symptom: every device_bash call aborts before executing anything with
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
The host-side file bridge (list / stage / commit on connected folders) keeps
working normally — only the in-VM shell is dead.

Scope: affects ALL connected folders at once — a local D: drive AND a Google
shared-drive mount alike — so it's the Plan9 share layer, not any one folder.
Moving the folder (incl. to C:) makes no difference. Multiple harness projects
on the one machine are blocked simultaneously.

Note for other 25H2 users: the Settings → Update history → "Uninstall updates"
route did NOT cleanly roll KB5124008 back here — KB5124008 disappears from the
removable list but winver still reports Build 26200.9445 after uninstall +
reboot, and the sandbox stays broken. A proper removal appears to need DISM /
wusa rather than the GUI. (I've chosen to stay patched and wait for a fix, since
this is a security cumulative.)

A Cowork-side fix (making the 9p/Plan9 mount compatible with the updated Hyper-V
components shipped in KB5124008) would be hugely appreciated — reverting a
security update isn't a viable long-term answer.

Adding one impact angle I don't see covered yet: scheduled / unattended Cowork tasks.

The failure itself is identical to what's already reported here — sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared, host side still lists the folders, and device_list_dir / device_stage_files / device_commit_files keep working throughout. Windows 11 25H2 x64, build 26200.9445 (KB5124008 installed, not rolled back). Claude Desktop 1.49585.0 (Electron 44.2.0, Node 24.20.0), two connected folders, both fail to mount. Persisted through 2026-09-09 local across four separate sessions — two scheduled, two interactive.

What I haven't seen mentioned is how this degrades when nothing is watching:

1. Two different failure modes on the same day, from the same scheduled task. Most runs hit the mount failure described in this issue — shell dead, file tools alive, so the staging workaround w00yay describes above is still reachable. One run failed earlier and harder: the workspace would not create at all, because the outputs mount source was gone. That run had no shell and no mirror, so there was no fallback available to it at all. Worth knowing that the recoverable and unrecoverable variants can alternate on one machine within a few hours.

2. There's nobody present to switch to the workaround. An interactive user reads the error and pivots to staging in a minute. A scheduled run just stops. Mine happened to detect the dead shell and write a "run skipped" marker instead of emitting output, but only because that guard existed for unrelated reasons — the default outcome is a silent no-op you discover much later, with no error surfaced anywhere the user routinely looks.

3. The first-order symptom points at the wrong layer. With the shell dead and the file tools healthy, the presentation is "can't reach the computer," which sends you at the bridge, the desktop app, and the connected folders before you ever suspect a Windows update. The hr=0x0 + mounted 0/N split makes that misdirection worse, since the host logs look clean.

None of this is a new diagnostic signal — pyjamasam's p9rdr.sys / p9np.dll A/B is clearly the one that matters. But if severity is being weighed, silent failure of unattended runs is a worse class of bug than an interactive error, and it's invisible from the host side by construction.

Happy to pull the guest/host logs from this machine if useful; I have not rolled back the KB.

Confirming this on a second machine, x64, Claude Desktop 1.49585.0, Windows 11 Pro 25H2, OS build 26200.9445 — the same build cited in this issue.

Get-HotFix -Id KB5124008 confirms it's installed:

Source        Description      HotFixID      InstalledBy          InstalledOn
------        -----------      --------      -----------          -----------
PHTHALO       Security Update  KB5124008     NT AUTHORITY\SYSTEM  9/9/2026 12:00:00 AM

That install date lines up almost exactly with when my Cowork sessions went from occasional Plan9 mount trouble to failing on every single bash call, including a bare echo test.

A couple of things that might help narrow this down further:

1. The error text isn't stable across restarts. First occurrence, the error was the one in this thread's title: sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared. After I fully killed the Claude desktop app (closed the window, then verified via Task Manager that every clau... process had exited) and relaunched, every session — including ones that predated the restart — started returning a different message instead: "Workspace unavailable. The isolated Linux environment on this device failed to start. Use device_stage_files / device_commit_files instead." No Plan9/virtiofs mention at all. Same underlying failure, presumably, but worth flagging in case that generic message is sending other affected users down a different search path than this thread.
2. The blast radius is narrower than "the sandbox is down." Everything that depends on the Plan9-mounted share fails (any shell command against a connected folder), but the following all kept working the entire time: folder listing/metadata for the connected folder, staging a file's actual content off the device and committing files back to it (i.e., whatever transport those use isn't going through the same Plan9 mount), and a local MCP server I have configured through the same desktop app (unrelated to the sandbox VM). So this looks specifically like the Plan9-share attach step failing, not a wholesale failure of the device link.

Haven't tried the wusa /uninstall /kb:5124008 fix yet — wanted to get a second confirmation logged first, since pulling a security update isn't free. Will report back if/when I do.

Second x64 machine confirming this, plus a mechanism I think explains both this issue and #92958, and four things that do not fix it.

Diagnostic report attached. Install ID 420e9e7b-e094-4784-801a-027a9bf83de2.

Environment. Windows 11 Pro 25H2, build 26200.9445, KB5124008 installed alongside KB5126052, KB5124007 and KB5123304. Claude Desktop 1.49585.0 (MSIX), Electron 44.2.0. AMD Ryzen 5 5600H. Claude Code 2.1.267 on the host, guest SDK 2.1.260. The connected folder is plain NTFS on a second physical drive. Every device_bash call fails with:

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

The mechanism: the app relies on post-start Plan9 hot-add, and that is what appears to have broken.

The compute system is created with an empty Plan9 device block:

"Devices": { ... "Plan9": {}, ... }

started, and the shares are attached afterwards. From a clean cold boot tonight:

22:49:16.113137 [HCS] HcsStartComputeSystem returned: hr=0x0
22:49:16.219229 [VM]  Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
22:49:16.219229 [HCS] HcsModifyComputeSystem returned: hr=0x0
22:49:16.222006 [VM]  Adding Plan9 share via HcsModifyComputeSystem: name=d path=D:\ port=9903 flags=0x10 hasToken=true
22:49:16.222720 [HCS] HcsModifyComputeSystem returned: hr=0x0
22:49:16.223226 [VM]  VM started successfully
22:49:19.124689 [VM]  Sent plan9Shares notification (2 shares)

Every host-side call returns success and the guest sees nothing.

"Worth saying plainly", this ordering is not new and is not itself the bug. I checked an older app-side log from before the break and the shares have always gone in after boot, on every boot, and it worked fine:

2026-08-17 23:56:35 [info] [VM:steps] vm_boot completed (108ms)
2026-08-17 23:56:35 [info] [VM:steps] add_plan9_shares started
2026-08-17 23:56:35 [info] [VM:steps] add_plan9_shares completed (1ms)

Identical on 08-12, 08-13, 08-14, 08-16 and 08-17, durations 0-12 ms, which also matches the historical range #92958 measured. So the app depends on attaching Plan9 shares to an already-running VM, that dependency held for weeks, and it stopped holding after the September update. That would make this issue and #92958 the same failure seen from two sides: the ARM64 report of "reports success, attaches nothing" and this issue's "hr=0x0, guest mount says invalid argument" are both post-start hot-add no longer reaching the guest.

If that is right, no user-side workaround can exist, because nothing a user controls affects when the app attaches its shares. Building the Plan9 devices into the HcsCreateComputeSystem config instead of an empty block plus a later modify would test it directly.

What does not fix it here. I tested these because both rollback tests, here and in #92958, included a reboot, which makes a reboot a variable rather than a control:

• Claude Desktop restart with the process confirmed gone from Task Manager. No change.
• Closing every other desktop application including the tray, in case of contention. No change.
• Full Windows shutdown and cold boot. No change.
• Enabling Cowork VM Debug Logging (Help > Troubleshooting). Adds only a KernelCmdLine dump. Nothing about the share attach, nothing guest-side.

The cold boot also cleared stale share state. Earlier boots logged Plan9 share 'c' already configured identically (path=C:\ port=9902), skipping, while the post-reboot boot logged Plan9 share added: c -> C:\ (port=9902, readOnly=false). Fresh registration, identical failure, so carried-over configuration is not the cause either.

I run several Cowork sessions at once against the same folder, on two machines with separate installations, so I first suspected session contention. A single session after a cold boot fails the same way, so concurrency is not required to reproduce it.

Where the logs live, which I do not see named anywhere on this tracker. Neither is under AppData, which is where I looked first:

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

The before and after. Last successful mount on this machine:

2026/09/08 23:27:47 [coworkd] mounted /mnt/.virtiofs-root/shared/d/<folder>
                    at /sessions/<id>/mnt/<folder> (mode=rw)

The machine rebooted into the updated build at 07:39 the next morning. There has not been one mount line since, across many sessions over two days.

Ruled out here. App Control for Business is enforced with HVCI and VBS running, and I checked it because a re-signed host component under an enforced policy would fail this way. CodeIntegrity logged only 3099 policy refreshes at Status 0x0, no 3076 or 3077 in the window. Nothing was denied. The user profile has OneDrive folder redirection that the connected folder does not sit under, so cloud sync is out without changing folders.

Unaffected, matching #92958. device_list_dir, device_stage_files and device_commit_files work throughout, including on a folder granted to a live session while device_bash stays dead on that same grant. The grant path and the share attach are separable.

The app is controlled for on this machine. Windows dates it from the service install records rather than from my recollection: each Claude Desktop update reinstalls the Cowork VM service, and SCM logs a 7045 naming the versioned install path.

2026-09-05 22:55:05  7045  Claude_1.46388.4.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe
2026-09-08 15:24:51  7045  Claude_1.49585.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

So 1.49585.0 landed at 15:24 on 2026-09-08. My last successful mount was 23:27 the same day, eight hours later, and the failure begins at the 07:39 boot the following morning after KB5124008 installed. The app version is identical on both sides of the break, so this machine does not lean on #92958's control for that. Those 7045 records are also a cheap way for anyone else on this thread to date their own app changes against their own break, since the app does not log its version at VM boot.

claude-diagnostic-redacted.zip

Independent confirmation, different machine, same conclusion, plus two data points the original report doesn't have.

Environment

• Claude Desktop 1.49585.0 (MSIX Claude_pzs8sxrjxfjjc), VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62, in-VM SDK 2.1.260, VM image files dated 2026-08-18 (unchanged across the break)
• Windows 11 25H2, 10.0.26200.9445 after KB5124008; WSL 2.6.3.0 / kernel 6.6.87.2-1, one distro (Ubuntu-22.04), working throughout
• Cowork VM is an HCS VM (cowork-vm-…, vmmem/vmwp, not a WSL distro); CoworkVMService running as LocalSystem

Timeline from %LOCALAPPDATA%\Claude\Logs\main.log + cowork_vm_node.log (all times local, 2026-09-08)

• 11:50 — Claude package 1.49585.0 installed
• 12:02 — VM boot on the new app; 22 [remote-bash] calls through 13:23, all succeed (no sandbox-helper lines). So the app update is not the trigger.
• 13:58 — user-initiated restart for Windows Update; three back-to-back reboots; 14:02:12 System log: KB5124008 and KB5126052 (.NET) installed
• 14:06 — first VM boot after the update; 14:07 first sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
• Every VM boot since (10+, across three further host reboots) fails identically. Before the update: 566 shell calls 9/4–9/7 and 152 on the morning of 9/8, zero failures, on 26100.9278 (KB5120997).

Host side is clean. Microsoft-Windows-Hyper-V-Compute-Operational at each VM create:

Modify compute system, settings '{"ResourcePath":"VirtualMachine/Devices/Plan9/Shares","RequestType":"Add","Settings":{"Name":"c","AccessName":"c","Path":"C:\\","Port":9902,"Flags":16}}', result 0x00000000
Modify compute system, settings '{"ResourcePath":"VirtualMachine/Devices/Plan9/Shares","RequestType":"Add","Settings":{"Name":"g","AccessName":"g","Path":"G:\\","Port":9906,"Flags":16}}', result 0x00000000

Sixteen seconds later, on the same host and boot, WSL adds its own Plan 9 shares (drivers, lib_inbox, lib_packaged, Flags 33) to its VM, and they mount fine in the guest (drivers on /usr/lib/wsl/drivers type 9p (ro,...,aname=drivers;...,trans=fd)). So the updated Plan 9 device still serves a Linux guest; what fails is specifically Cowork's Flags-16 / token-based shares, consistent with the original report.

Not share-specific (new data point). The app registers G:\ on every VM create from what appears to be a persisted list — it kept registering G:\ after Google Drive (the only thing that ever provided G:) was exited and G: no longer existed on the host. To rule out "one unservable share breaks the rest," I created a 63 MB NTFS VHDX and gave it G: (a real mount-manager volume, visible to LocalSystem), quit/relaunched Claude (HCS shows Terminate then Create, so restarts really do rebuild the VM), and got the same result: both shares registered with result 0x0, 0 mounted. The failure is per-share and universal, not caused by a bad path.

Also not fixed by: app restarts (four on 9/9 alone), host reboots, a clean VM re-create, or adding a folder mid-session (folders on C: are bound inside the existing c share; no new HCS share is issued).

Rollback: KB5124008 removed via DISM /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26, reboot → 26200.9278 → first VM boot mounts all shares; device_bash works; scripts run against the mounted folders. Nothing else changed.

Two secondary issues worth their own tickets

1. The host records nothing about the guest's mount outcome. add_plan9_shares completed (7ms) is just the HCS call; the only trace of the failure is the [vm-stderr oneshot-] line when a user actually runs a command. The per-share mount result should be logged host-side at VM boot and surfaced in the device_bash error instead of "failed to mount and cannot be reached."
2. The drive-share list is stale: a drive that no longer exists (G:\) is registered on every boot, with no way for the user to see or clear the list.

Confirming a second independent occurrence on a different machine, with a few extra data points that narrow the cause.

Matching environment

• Windows 11, build 10.0.26200.9445 (KB5124008 installed)
• Claude Desktop 1.49585.0, Electron 44.2.0
• Identical guest-side symptom: sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared, failing before any command executes

Differences from the original report, which rule out several confounders

• Antivirus is ESET Security, not Bitdefender. I tested this directly: full app exit, vmmem confirmed gone from Task Manager, ESET real-time protection paused, then relaunch. The failure reproduced identically on the clean VM boot. So the regression is not AV-specific, and AV is not the trigger.
• No mapped SMB network drives. A single plain local NTFS folder, so the fault does not require the 8 mapped drives in the original setup.
• Not x64-vs-ARM specific, since this is x64 as well.

Additional finding: independent of folder size or content

I connected a brand new folder containing one 9-byte text file, alongside the existing project folder (a repo with 10,000+ entries). Both failed to mount in the same call:

mnt/contekz-lore, mnt/claude-mount-test failed to mount

So this is not an enumeration or timeout problem on large trees. A folder with a single tiny file fails exactly like a large repo.

Also ruled out here

• WSL health is fine and is a red herring for triage. WSL 2.6.3.0, kernel 6.6.87.2, distro Running, vmcompute and HvHost running, no Hyper-V compute errors logged. As the original report notes, WSL2 drvfs keeps working with the KB installed, which makes every WSL diagnostic come back clean while Cowork stays broken.
• .wslconfig settings are irrelevant, including networkingMode=mirrored. The Cowork sandbox is its own Hyper-V VM (vmmem) and does not appear in wsl --list --all, so wsl --shutdown has no effect on it.
• Folder permissions are intact. Reads and writes both verified working through the file-transfer path.

Useful triage detail: only the shell is affected

The file-transfer tools (device_list_dir, device_stage_files, device_commit_files) all continue to work normally against the same folders, including writes. Only device_bash is broken. That asymmetry is a reasonable workaround for anyone blocked on this, since files can still be staged to the cloud container, processed there, and committed back. The notable gap is deletion, which routes through the shell.

On the error message

Agreed with the original report that the messaging is misleading. The host reporting success while the guest mounts 0/N sends people down AV, WSL, and permissions paths for hours. Surfacing the guest-side Plan9 mount failed: invalid argument in the user-facing error, or detecting the affected Windows build and naming KB5124008 directly, would save a lot of wasted troubleshooting.

I have not uninstalled the KB on this machine, since it is a cumulative security update and the staged-file workaround is adequate for now. Happy to run any diagnostics that would help, or to test a candidate fix.

Second confirmed machine (x64), plus a deeper trace of where the break actually is
NOTE - I submitted this same 'second confirmed machine' above, but now there are some additional insights and a reasonable ask for Anthropic

Confirming this on a second x64 machine: Windows 11 Pro 26200.9445, KB5124008 installed 2026-09-09, Claude Desktop 1.49585.0, VM SDK 2.1.260, bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62. Identical symptom and log signature, with the host reporting success and the guest mounting nothing:

2026-09-09 10:21:53 [info] [VM:steps] add_plan9_shares completed (64ms)
2026-09-09 15:33:17 [warn] [vm-stderr oneshot-] sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

Repeats across every VM restart, so an app relaunch never clears it.

1. The host-side Plan9 server is vp9fs.dll, which isn't in this issue's file list

Scanning every binary in System32 for Plan9 protocol strings returns six files. vmwp.exe and vmcompute.exe contain zero:

p9np.dll             plan9
p9rdrservice.dll     plan9
vmsmb.dll            Plan9FileSystem
vp9fs.dll            9P2000.L  9P2000.W  Plan9  Plan9DeviceHost
hcsdiag.exe          Plan9Share
drivers/p9rdr.sys    9P2000.L  9P2000.W  plan9

vp9fs.dll carries Plan9DeviceHost and both dialects including 9P2000.L. It is loaded by the VM worker process rather than compiled into it, which is why it does not show up by grepping vmwp.exe. Worth noting that p9rdr.sys and p9np.dll are the Windows-side 9p client redirector (\\wsl$) and are not in this failure path at all, so anyone tempted to downgrade just those will be disappointed.

2. Version history and diff of vp9fs.dll

WinSxS retains each serviced version with its install date:

| Version | Landed | Size | SHA-256 (first 16) |
|---|---|---|---|
| .8875 | 2026-07-14 | 329,192 | f8777f9ebc0d71f6 |
| .8972 | 2026-08-11 | 329,208 | b6a44ae59bb5ebad |
| .9278 | 2026-09-09 (KB5124008) | 329,184 | 71ce254f2025bef5 |

Live System32\vp9fs.dll is byte-identical to .9278, so .8972 is what ran during the last known-good window.

Diffing .8972 against .9278: of 41,484 differing bytes, .rdata accounts for 34,354, the signature blob 6,049, and .pdata 922, leaving .text at only 131 bytes out of 214,148 (0.06%), in a few short runs near the start. The UTF-16 string diff is empty; the ASCII diff is entirely code-signing noise. No new strings, no new imports. Consistent with a small targeted validation change rather than a redesign.

3. What the guest actually asks for

From smol-bin.vhdx in the VM bundle:

| | |
|---|---|
| Guest kernel | Linux 6.8.0-136-generic |
| Helper | /usr/local/bin/sandbox-helper (Go, coworkd/cmd/sandbox-helper) |
| Mount options | trans=fd,rfdno=%d,wfdno=%d,msize=%d,noload,aname=%s |
| Log format | [coworkd] SDK source on 9p mount, negotiated msize=%d, copy buffer=%d |

trans=fd means the helper opens the connection and hands the file descriptors to the kernel's 9p client. So the HCS attach and the guest mount are genuinely two separate steps, which is why hr=0x0 alongside a failed mount is not a contradiction.

4. Hypothesis (clearly labeled as such): msize negotiation

No version= is specified, so the dialect is negotiated, and msize is explicitly negotiated. With trans=fd, an EINVAL from mount() most plausibly arises in client setup and the version handshake rather than in the transport, and msize is the natural suspect, because Linux's 9p client rejects a negotiated msize outside the acceptable range with EINVAL. A host that now clamps or validates msize differently would produce exactly this: attach succeeds, mount fails, totally rather than intermittently. msize governs host-side buffer sizes, which is a plausible spot for a hardening check.

I cannot confirm this without the guest kernel's own log line, and I have no route to it (see below).

5. Two practical notes

hcsdiag cannot be used to test this. I tried, so others do not need to. hcsdiag list (elevated) does show the VM, but both share and exec return The request is not supported (ERROR_NOT_SUPPORTED), and the GUID is not accepted as an identifier, only the name. Presumably because the guest runs a custom agent over vsock rather than Microsoft's guest compute service. So there is no vendor-neutral repro available through Microsoft's own tooling.

There is no retry, and that may be the cheapest fix. sandbox-helper reads only four environment variables (CLAUDE_CODE_OAUTH_TOKEN, CLAUDE_CODE_TMPDIR, CLAUDE_TMPDIR, CLAUDE_BG_AUTH_SNAPSHOT_PATH), none affecting the mount, and msize is not tunable from outside. It makes one attempt at one msize and gives up. If the hypothesis in (4) is right, a single retry at a smaller msize would restore service on every affected machine from the Anthropic side alone, with no Windows change and no security tradeoff.

HEY ANTHROPIC... Two small asks

1. Log the guest-side failure detail. Right now only sandbox-helper's summary verdict reaches the host log. Surfacing the actual mount() errno, or the relevant dmesg lines from the v9fs client, would confirm or kill (4) immediately, and would have shortened this investigation by hours.
2. Consider a retry ladder on msize as an interim mitigation while the Windows-side regression is unresolved.

Additional data point: same regression on Windows 11 ARM64, triggered by
KB5124008 — which links this issue with #92958 (ARM64, but KB5124012).

Environment

• Windows 11 ARM64, build <BUILD EINSETZEN>, KB5124008 installed unattended overnight 2026-09-10
• Claude Desktop 1.49585.0 (MSIX, arm64), Cowork VM SDK 2.1.260
• VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 (identical to OP)

Onset is unambiguous. cowork_vm_node.log covers 2026-08-21 to 2026-09-10.
"no Plan9 drive shares mounted" appears for the first time at 2026-09-10
05:32:30, on the first shell command after the KB5124008 reboot. Not once in
the preceding three weeks.

Host reports full success. Every step of the post-reboot startup completes:

create_network completed (3ms)
create_vm_config completed (122ms)
vm_boot completed (187ms)
add_plan9_shares completed (6ms)
Network status: CONNECTED
sdk_install completed (1476ms)
Startup complete, total time: 5912ms
API reachability: REACHABLE

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

Note for anyone triaging: the add_plan9_shares duration is not a signal.
Across 20 startups in the log it ranges 0–17 ms, on working and broken days
alike. 6 ms is normal, not evidence of an empty share list. I chased that
false lead.

Secondary failure mode worth documenting. Restarting the desktop app while
in this state made things worse: it terminated the still-connected (share-less)
VM, and the service CoworkVMService (display name "Claude") was left
Stopped with StartType Automatic and was not started by the app on
launch. The error then changed from the Plan9 message to
Workspace unavailable. The isolated Linux environment on this device failed
to start. Every subsequent app restart stopped the service again. A Windows
reboot restored the service — and the Plan9 failure was still there
underneath. So the two symptoms are distinct and the app restart only masks
the real one.

Ineffective: wsl --update (to 2.7.13), manual Start-Service, multiple
app restarts, a full Windows reboot.

Confirmed fix: wusa /uninstall /kb:5124008 + reboot. All six connected
folders mount, device_bash works, verified end to end by opening a 26 MB
SQLite database located on a mounted share.

Suggestion, seconding the OP: the guest-side mount count should be
surfaced as a startup error. Reporting Startup complete and
add_plan9_shares completed while the guest mounted 0 of N shares is what
made this take a morning to isolate — every host-side signal says healthy.

Same issue here — confirming on another machine.

******Update Confirmed: uninstalling KB5124008 + reboot fixed it on my machine too*********

Environment

• Windows 11 Pro 24H2, build 10.0.26200 (Japanese locale), x64, company PC
• Claude Desktop from Microsoft Store (MSIX Claude_..._pzs8sxrjxfjjc), auto-updated to latest
• KB5124008 installed via Windows Update on 2026-09-09 (evening JST), PC shut down afterwards; first Cowork launch on 2026-09-10 morning failed

Symptom
Every bash/sandbox call fails immediately with:

failed to mount /mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/.../outputs as outputs: source path ... is under Plan9 share "c" which is not mounted
create: RPC error -1: ensure user: user <session-user> already exists unexpectedly: uid=1040 gid=1040

File tools (Read/Write/Edit), browser and computer-use still work; only the Linux sandbox is dead, so anything needing Python/LibreOffice (PDF/DOCX/XLSX generation) is impossible.

What did NOT help (tried several times)

• Fully quitting Claude Desktop from the tray and relaunching, new Cowork session
• wsl --shutdown
• Full PC reboot (multiple)
• Verified Virtual Machine Platform is enabled

Not yet tried: uninstalling KB5124008 (company-managed PC, needs admin approval).

Since this is a security update, a Cowork-side fix would be much better than asking users to stay unpatched. Happy to provide cowork_vm_node.log / coworkd logs if useful.

Confirming this on a second machine, same root cause.

Environment

• Windows 11 Pro 24H2, build 26200.9445
• KB5124008 installed 2026-09-09 (confirmed via Get-HotFix -Id KB5124008)
• Claude Desktop 1.49585.0 (MSIX package)

Symptom — identical to the original report: every Cowork session fails to
start its workspace with Plan9 share "c" is not mounted, 0 shares mounted.
WSL2 is completely unaffected (I ran wsl --shutdown + wsl --update to 2.7.13
with no change), which matches your finding that the regression is specific to
Cowork's Plan9 shares.

Workarounds tried, none worked: multiple reboots, wsl --shutdown/--update,
full app quit from tray + relaunch, App Repair, and finally Reset Application Data.

The part worth escalating: because the KB was not known to be the cause, the
documented "last resort" (Reset) was the natural next step — and it permanently
destroyed the machine's entire local Cowork session history (~200 sessions). So
this Windows-patch regression, with no in-app indication of the cause, funnels
users straight into the one action that causes data loss (see #65695). The
timeline was: KB installs → sandbox breaks → full-day troubleshooting → Reset →
session loss, all in one day.

A build compatible with the updated p9rdr.sys / p9np.dll (10.0.26100.9278–.9444)
is the real fix; uninstalling the KB is not something security-conscious users
should have to do.

Confirming this on a second machine, same Claude Desktop build as the reporter.

Environment

• Claude Desktop 1.49585.0
• Windows 11 Pro 24H2, build 10.0.26200
• KB5124008 installed 2026-09-09 (Security Update, installed by NT AUTHORITY\SYSTEM)
• Connected folders: one plain local NTFS folder on C:, one Dropbox-synced folder

Timeline

• Last known good: 2026-09-09, ~07:20 local — a scheduled task ran Python inside the

sandbox without any problem.

• KB5124008 installed the same day; effective after the following reboot.
• First failure: 2026-09-10, ~07:10 local — every bash call fails instantly, and it

has failed on every call since.

Symptom
Instead of no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared, the helper
here reports the missing share per mount target, and the fallback path fails too:

bash failed on resume, create, and re-resume.
resume: RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/<user>/... as outputs:
source path /mnt/.virtiofs-root/shared/c/Users/<user>/... is under Plan9 share "c"
which is not mounted;
create: RPC error -1: ensure user: user <workspace> already exists unexpectedly: uid=1182 gid=1182

The second half looks like a separate defect: the "create a fresh workspace" fallback
aborts because the guest user from an earlier session is still present, so there is no
self-recovery once the shares are gone.

What did not help

• Several full reboots of the host
• Quitting and restarting Claude Desktop several times

Both a plain NTFS folder and a Dropbox-synced folder are affected, which matches your
observation that this is not a cloud-files problem.

Not attempting the KB uninstall here — it is a security patch on a work machine.

Same issue here — Windows 11 Home, and the KB cannot be uninstalled (0x800f0905)

Confirming this on a second machine with a different edition:

• Claude Desktop 1.49585.0.0 (MSIX, Store), Cowork VM SDK 2.1.260
• Windows 11 Home 25H2, build 26200.9445 (KB5124008 installed 2026-09-09 18:26 KST)
• Hyper-V compute services running (vmcompute, HvHost); no Hyper-V-Compute/Worker event log errors — VM starts normally
• Antivirus: AhnLab V3 Lite + Defender (disabling V3 made no difference)

Timeline: Claude auto-updated to 1.49585.0 at 01:43 on 09-09 and Cowork worked all day. KB5124008 was applied at 18:26; every session since fails with:

RPC error -1: failed to mount .../uploads as uploads: source path ... is under Plan9 share "c" which is not mounted

and on a freshly re-downloaded bundle:

RPC error -1: SDK version 2.1.260 not verified at /mnt/.virtiofs-root/shared/c/.../claude-code-vm/2.1.260/.verified

(the .verified file exists on the host — the guest simply can't read anything through share "c").

What did NOT help: multiple reboots; killing cowork-svc + hcsdiag kill; renaming sessiondata.vhdx; renaming rootfs.vhdx (clean 7.9 GB re-download); "Reinstall workspace" from the error banner; freeing 23 GB on C:; disabling AV.

Unlike the OP, the KB will not uninstall on this machine. All of these fail with 0x800f0905:

• wusa /uninstall /kb:5124008
• Settings → Windows Update → Uninstall updates → KB5124008
• dism /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26
• WinRE → Troubleshoot → Uninstall latest quality update ("There was a problem…")
• No system restore points available (0x80004005)

So for users who can't roll back the KB there is currently no workaround at all — a Cowork-side fix for the 9p mount against the updated Hyper-V Plan9 server would be very welcome. Happy to provide cowork_vm_node.log / coworkd guest logs if useful.

Also note #92958 reports the same failure on ARM64 with the sibling KB5124012, so this looks like the September 2026 cumulative update across architectures rather than a single-machine issue.

Second independent confirmation — Windows 11 Home 25H2, and no WSL installed

Same failure, same KB, same build, different edition. Confirming your report.

Environment

| | This machine | Yours (for contrast) |
|---|---|---|
| Windows | 11 Home 25H2 | 11 Pro 24H2 |
| Build | 26200.9445 (KB5124008) | 26200.9445 (KB5124008) |
| Architecture | x64 | x64 |
| Claude Desktop | 1.49585.0 (MSIX) | 1.49585.0 (MSIX) |
| VM bundle | 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 | same |
| WSL | not installed at all | WSL2 present, still working |

Two things this adds:

1. Not edition-specific. Home 25H2 fails identically to Pro 24H2.
2. WSL is irrelevant in both directions. You have WSL2 and it keeps working; this machine has no WSL installed at all (wsl --status → "The Windows Subsystem for Linux is not installed") and Cowork fails exactly the same way. So WSL is neither a cause nor a mitigation — which further supports your conclusion that the defect is specific to Cowork's token-based share request (flags=0x10 hasToken=true).

Identical guest-side error

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

Verbatim match with your report. Reproduced again today (2026-09-10), two days after the update, with a freshly granted folder (C:\Users\<user>\Documents, plain local NTFS, not cloud-synced).

Regression window pinned from cowork_vm_node.log

| Event | Timestamp |
|---|---|
| Last successful access to a mounted host folder | 2026-09-08 20:23:45 |
| First start with no shares attached | 2026-09-09 09:09:40 |
| KB5124008 installed | 2026-09-09 |

Get-HotFix for that window:

HotFixID   InstalledOn
KB5126052  09.09.2026     (.NET Framework 3.5/4.8.1 — unrelated)
KB5124008  09.09.2026     <- the cumulative
KB5124007  08.09.2026

No app update in that window (Claude Desktop stayed on 1.49585.0), no VM bundle change, no config edits.

Host-side log looks completely healthy

2026-09-09 14:01:38 [info] [VM:steps] vm_boot completed (248ms)
2026-09-09 14:01:38 [info] [VM:steps] add_plan9_shares started
2026-09-09 14:01:38 [info] [VM:steps] add_plan9_shares completed (17ms)
2026-09-09 14:01:41 [info] [VM] Network status: CONNECTED
2026-09-09 14:01:43 [info] [VM:start] Startup complete, total time: 7749ms
2026-09-09 14:01:43 [info] [VM] API reachability: REACHABLE

cowork_vm_node.log contains no error and no HRESULT for the share step — grepping the whole 3971-line file for not mounted|virtiofs|no Plan9 returns 0 hits. This matches your host-side hr=0x0 observation: the host believes it succeeded.

One note in case it saves someone a wrong turn — add_plan9_shares duration is not a signal. Issue #92958 quotes "(4-12ms)" in a way that might read as diagnostic. In this log the step is fast both when mounts worked and when they don't:

2026-08-21 11:39:50   (37ms)   working
2026-09-05 11:34:25   (84ms)   working
2026-09-08 21:12:25   (14ms)   working   <- last session before the update
2026-09-09 09:09:40   (19ms)   BROKEN
2026-09-09 14:01:38   (17ms)   BROKEN
2026-09-10 07:27      (n/a)    BROKEN    <- still broken two days later

Also tried here, also useless

Restart-Service vmcompute -Force + full app restart → no change. Consistent with your list.

What still works

Folder grants persist across restarts, and device_list_dir / device_stage_files / device_commit_files all work normally against the same folder that the in-VM shell cannot see. Only the guest shell is cut off. That is a usable workaround for file work (stage → process elsewhere → commit back), and worth documenting for anyone who cannot roll back.

Not rolling back here

KB5124008 carries the September security fixes, so I am staying on it rather than reproducing your wusa /uninstall A/B. Your uninstall test plus this second machine on a different edition should be enough to establish the cause without more people removing a security update.

The part that looks actionable client-side

Your finding that WSL2's Plan9 shares keep mounting while Cowork's token-based shares fail suggests this may not require waiting for a Microsoft fix. If the hasToken=true / flags=0x10 path is what the updated p9np.dll / p9rdr.sys now reject, is there a fallback Cowork could use, even a degraded one?

Separately, +1 to your third request: VM started successfully followed by mounted 0/9 Plan9 shares with no surfaced error cost several hours of misdiagnosis on this end — including chasing WSL, Hyper-V reinstall and app reinstall, none of which were relevant. A hard failure at startup when 0 shares mount would have pointed straight at the cause.

Related

#92958 describes what is very likely the same defect on the other servicing branch (ARM64, 26H1, KB5124012, build 28000.2954). Between that report and these two x64 machines on KB5124008, this looks like a change common to the whole September 2026 servicing branch rather than anything branch- or architecture-specific. Cross-linking so the two do not get triaged separately.

Confirming on Windows 11 x64 (KB5124008), non-ARM

Same failure here, matching this report in every detail I could check.

Environment

• Lenovo Legion 5 Pro, Windows 11 x64, KB5124008 installed
• Claude Desktop 1.49585.0 (MSIX), Electron 44.2.0, Node 24.20.0
• Cowork SDK 2.1.260, VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62

Symptom

Host reports success, guest mounts nothing:

[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed (25ms)
[vm-stderr oneshot-] sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

device_bash fails before any command runs. device_list_dir, device_stage_files and device_commit_files remain fully functional throughout, as does the local playwright MCP server — only the shell is affected.

Timeline

Last successful device_bash: 2026-09-08. First failure: 2026-09-09 12:13 local, on the first invocation after the machine had been updated. No app or config changes by me in between.

Ruled out (all tested, all still failing)

• New session / new session ID; app restart; two full OS restarts
• Folder path: fails identically for a OneDrive folder and a plain local one (C:\Users\<user>\Downloads)
• Defender: Controlled Folder Access disabled, realtime monitoring on, no third-party AV
• Virtualization healthy: hypervisor detected, HvHost and vmcompute both Running
• CoworkVMService Running, StartMode Auto, StartName LocalSystem
• Deleted rootfs.vhdx → re-extracted from rootfs.vhdx.zst, no change
• Deleted the entire claudevm.bundle + warm cache → full re-download; the new rootfs.vhdx.zst is byte-identical in size to the old one, so the bundle is current
• Deleted claude-code-vm\2.1.260 → reinstalled by the app, no change
• MSIX "Repair" via Windows Settings, followed by a restart

Secondary symptoms observed while trying the above

• With a freshly extracted rootfs: RPC error -1: SDK version 2.1.260 not verified at /mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Roaming/Claude/claude-code-vm/2.1.260/.verified — the host had written that file seconds earlier, so this looks like the same unmounted-share problem surfacing on a different code path
• Fully quitting the app stops CoworkVMService and it does not restart on its own; the app logs VM service not running ... a computer restart restores it, which is accurate but easy to mistake for a separate fault

I have not uninstalled KB5124008 yet, so I cannot add an A/B data point — but every user-side cause I could think of is excluded, and the version fingerprint here is identical to the original report.

Confirming #92984 on a second x64 machine, with A/B in both directions on the same app version.

ENVIRONMENT

• Windows 11 Home 25H2, x64 — build 26200.9445 after KB5124008, MSIX/Store install of Claude
• Claude Desktop 1.49585.0 · Electron 44.2.0 · Node 24.20.0 · VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62
• Hyper-V/VMP, CoworkVMService Running, HvHost/vmcompute Running. No WSL at the time of failure

(installed later as a test, no change).

TIMELINE (local, UTC+2), from cowork_vm_node.log and the System event log

• 08.09 06:56:30 add_plan9_shares completed — last VM boot with working shares (device_bash OK all day)
• 08.09 20:22 KB5124008 install started (event 43); app updated to 1.49585.0 via Store at 20:56
• 08.09 21:02–21:06 reboot chain (TrustedInstaller 1074 ×2)
• 09.09 04:21:09 first VM boot on the patched host: add_plan9_shares completed (25ms), no error
• 09.09 04:23:51 first "sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared"
• 09.09–10.09 every device_bash call fails identically (≈60 occurrences logged), across 5+ sessions,

3 full reboots, app restart. device_list_dir / stage / commit keep working throughout.

• 10.09 ~09:30 wusa /uninstall /kb:5124008, reboot, Windows Update paused
• 10.09 09:42 device_bash works again: all 6 connected folders mounted (FUSE, rw), python runs, writes land

HOST COMPONENTS REPLACED BY THE KB (all stamped 08.09 19:32, before the reboot)
p9rdr.sys 10.0.26100.9444 · p9np.dll 10.0.26100.9278 · vmcompute.exe 10.0.26100.8875
vmwp.exe 10.0.26100.8875 · computestorage.dll 10.0.26100.9444
— same set as reported above.

WHAT THIS ADDS TO THE ISSUE

1. Windows 11 HOME (the original report is Pro), MSIX/Store install, same result — so it is not

edition- or installer-specific.

1. The app update (1.49585.0, 20:56) and the KB (20:22) landed within the same hour on this machine.

That is a confound in my data, not evidence against the app: I resolved it by uninstalling the KB
with the app unchanged at 1.49585.0 → shares mount again. Same conclusion as the two A/B tests
already on this thread.

1. Failure is independent of filesystem/location: cloud-synced folder (Proton Drive) and a plain

NTFS folder under C:\Users\<me>\dev fail together — 0 shares mount, not per-folder failures.

1. Host side logs SUCCESS for add_plan9_shares on every boot; the only error is guest-side

(sandbox-helper). Nothing in the app UI tells the user the shell is gone; the first signal is a
failed tool call.

ASK

• Please treat this as a P1: every Windows Cowork user who took September Patch Tuesday loses

device_bash entirely, and the only user-side fix is removing a security update that patches two
exploited local-EoP CVEs (CVE-2026-85880, CVE-2026-81963). I do not want to run unpatched for weeks.

• If the fix is guest-side (9P mount options vs the new p9rdr), can it ship through the VM bundle

without waiting for an app release?

• A visible warning in the app when 0/N shares mount would have saved me two days of misdiagnosis.

Happy to provide cowork_vm_node.log / main.log or run a test build.

Same regression on an independent machine, with a different surface symptom and a double A/B confirmation.

Environment — identical to the original report:

• Claude Desktop 1.49585.0 (MSIX Claude_pzs8sxrjxfjjc), VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62, SDK 2.1.260
• Windows 11 Pro, build 10.0.26200 → 26200.9445 with KB5124008

Different error string. Instead of Plan9 mount failed: invalid argument, my host-side log shows the downstream consequence — the SDK verification file cannot be found because nothing is mounted under the share:

[error] [VM:start] Startup failed: Error: RPC error -1: SDK version 2.1.260 not verified at
/mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/
LocalCache/Roaming/Claude/claude-code-vm/2.1.260/.verified

This repeated identically on every start. After the KB was reinstalled by Windows Update, the raw form appeared too:

RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/<user>/... :
source path ... is under Plan9 share "c" which is not mounted

Secondary effect worth noting. After ~10 hours of repeated failures the app gave up on the platform entirely and stopped attempting to start the VM at all:

22:42:20 [cleanupVMBundleIfUnsupported] yukonSilver not supported (status=unsupported)
22:43:31 [warn] [startVM] VM not supported (win32/x64), skipping

This masks the real cause completely — the UI reports the device as unsupported, which sends users chasing virtualization/BIOS/WSL settings instead of the KB. Whatever probe sets status=unsupported appears to be tripped by the mount failures.

Timeline (local, UTC+2)

| Time | Event |
|---|---|
| 09-09 ~12:05 | last working sandbox session |
| 09-09 12:14 | [Bundle:status] rootfs.vhdx missing |
| 09-09 12:16:36 | first .verified error, then identical on every start |
| 09-09 22:42 | app flips to yukonSilver not supported |
| 09-09 23:09 | wusa /uninstall /kb:5124008 + reboot |
| 09-09 23:15:30 | Package KB5124008 successfully changed to the Absent state |
| 09-09 23:16:45 | sandbox working again — 75 s after removal, no other change |
| 09-10 | KB5124008 reinstalled by Windows Update → broken again |

So the causality is confirmed in both directions: removing the KB fixed it, reinstalling it broke it again.

What did NOT help (in addition to the original report's list): uninstalling the MSIX build and reinstalling Claude Desktop from the standalone .exe installer. Same failure — so this is not specific to the packaged/MSIX install.

Agreed with the original reporter that staying unpatched on a September security update is not an acceptable long-term workaround, especially on managed corporate/university machines where Windows Update reinstalls it automatically.

Independent confirmation on x64, same app version.

Environment

• Claude Desktop: 1.49585.0
• Windows 11 25H2, build 26200.9445
• KB5124008: installed 2026-09-09
• Architecture: x64 (not ARM64 — distinct from #92958)
• 2 connected folders in the session

Timing correlation
KB5124008 was installed on 2026-09-09 and the failure was first observed the
same day, on the first device_bash call of that session.

Symptom
Every device_bash call fails immediately with:

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

followed by:

[Note: mnt/<folder-a>, mnt/<folder-b> failed to mount and cannot be
reached from this shell.]

Notable detail — the failure is scoped to the VM mount only

device_list_dir, device_stage_files and device_commit_files all keep
working normally against the exact same connected folders, in the same
session, throughout. Reading, staging and committing files to those folders
succeeds. Only the shell's view of them is missing. So the host↔desktop path
is healthy; what fails is the guest-side 9p mount.

Reproduction

• 100% reproducible, every call, over a two-day session (2026-09-09 and

2026-09-10)

• Persisted across a full OS reboot (the machine was rebooted for unrelated

reasons mid-session; the failure was identical before and after)

• Folder access was granted mid-session; re-granting changes nothing

Not attempted
Uninstalling KB5124008. This is a domain-joined workstation and the KB is a
cumulative security update, so removing it is not an acceptable trade-off
here. Reporting instead in the hope of a guest-side fix.

Happy to provide further logs on request.

Confirming this fix works for me too.

Environment: Windows 11, Claude Desktop, Cowork (local agent mode). I was hitting the same failure repeatedly — Cowork's virtiofs/Plan9 mount for connected folders would fail with the RPC error described in this issue, blocking me from working with local files through the desktop app's local agent mode.

After uninstalling KB5124008 (build 26200.9445, September 2026 cumulative update) and rebooting, the mount started working again and Cowork could reach my connected folders normally.

This strongly suggests KB5124008 is a real trigger for this regression, not just a coincidence for the original reporter. Given how disruptive this is (it fully blocks local file access in Cowork on Windows), it'd be great to get a fix that doesn't require staying off a security update. Happy to provide more details (build number, exact repro steps) if useful.

Update: sandbox restored here, plus one diagnostic gotcha worth flagging

Follow-up to my earlier comment on this machine (Windows 11 Home 25H2, x64, no WSL installed).

Status: the Cowork sandbox started mounting again as of 2026-09-10 08:10 UTC, after I uninstalled KB5124008 and rebooted. Claude Desktop is unchanged at 1.49585.0 and the VM bundle hash is unchanged (2a762adfc2eea13eca0d113a2e6452ff00ae3f62), so nothing shipped from the app side — removing the KB is the only change.

That makes this a third independent A/B confirmation that KB5124008 is the trigger, and the first on Windows 11 Home. Correcting my earlier comment, where I said I was staying on the update: I did roll back after all.

Verified working, in this order, on a freshly granted plain local NTFS folder:

| Operation | Result |
|---|---|
| ls ~/mnt/Documents | real host contents returned |
| write | file created and read back |
| delete | rm succeeds |

So the recovery is complete rather than partial — read, write and delete all behave normally again. Worth noting because the staged-file workaround discussed above covers reads and writes but not deletion, which routes through the shell.

Diagnostic gotcha: mount | grep 9p returns nothing even when it IS working

This cost time here and may cost others some, so flagging it explicitly.

In the guest, Cowork layers FUSE over the Plan9 share. A fully working mount looks like this:

/run/coworkd/hidefs/oneshot-<id>/Documents on /sessions/<id>/mnt/Documents
  type fuse (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

No 9p string anywhere. Grepping the guest mount table for 9p / plan9 / virtiofs returns zero hits whether the sandbox is healthy or broken, so it is worthless as a health check — I briefly read a working sandbox as broken because of it.

The reliable guest-side test is simply whether ls ~/mnt/<folder> returns content. Host-side, per the earlier analysis in this thread, the only real signal is the guest's own mount result, which is exactly what is missing from the logs today.

Correction to my earlier comment

I referred to p9np.dll / p9rdr.sys as the components in the failure path, following the file list in the original report. Per @bdmanevitz's binary analysis that is wrong: those are the Windows-side 9p client redirector (\\wsl$) and are not in this path at all — the host-side server is vp9fs.dll. Flagging it so nobody follows my earlier wording into a dead end. That comment's question about a fallback still stands, just against the right component.

On the proposed retry ladder

+1 to the msize retry suggestion. From a user's point of view the difference matters a lot: rolling back a cumulative security update to get a working sandbox is a bad trade, and I only did it after two days with no client-side option. A retry at a smaller msize, if that hypothesis holds, would let people stay patched.

Independent confirmation on x64, plus a couple of data points that may help narrow it down.

Environment

• Claude Desktop 1.49585.0 (MSIX Claude_..._pzs8sxrjxfjjc), CoworkVMService running
• Windows 11 Pro 25H2, build 26200 → 26200.9445 with KB5124008
• The affected machine is itself a VM guest on a KVM/Proxmox host (nested virtualization); HypervisorPresent = True
• Only 2 Plan9 shares configured here: c (C:\) and one mapped network drive

Timeline (local time)

• 08 Sep 19:58:36 — guest log: mounted 2/2 Plan9 shares — last known good
• 08 Sep 20:57–20:59 — KB5124008 replaces vmcompute.exe, vmwp.exe, computestorage.dll, p9np.dll, p9rdr.sys, vmbusr.sys
• 08 Sep 23:48 onwards — every VM start: the host adds both shares, HcsModifyComputeSystem returns hr=0x0, sdk-daemon connects, CA certs install — but the sandbox cannot use the shares
• 10 Sep — wusa /uninstall /kb:5124008 + reboot → sandbox works again immediately

So the uninstall fixes it here too, and this is with only two shares, so the failure does not depend on having many mapped network drives.

A different surface error, same root cause — adding it so others searching find this issue:

bash failed on resume, create, and re-resume.
resume: RPC error -1: failed to mount ... as outputs:
  source path ... is under Plan9 share "c" which is not mounted;
create: RPC error -1: ensure user: user <name> already exists unexpectedly: uid=1190 gid=1190

The second half is a side effect, not a second fault: resume fails, the code falls through to create, and finds the user it had half-created. A new uid is allocated per session and they all fail the same way.

The data point I think matters most. The guest console log (C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log) stopped being written entirely from the first post-KB boot onwards, while the VM was otherwise alive — RPC connected, sdk-daemon is ready, CA certificates installed in guest. That log goes over the virtio console port (/dev/vport0p0), not over 9p. In the original report the silent guest log was attributed to a stale VM bundle; here it happens on the same bundle that had been logging normally three hours earlier, which separates the two explanations. If the 9p mounts and the virtio console die together, the regression may sit below 9p — in VMBus — rather than in the Plan9 server itself.

File versions, before and after the uninstall

| Binary | With KB5124008 | After uninstall |
|---|---|---|
| vmcompute.exe | 10.0.26100.8875 | 10.0.26100.8875 — unchanged, so not the vector |
| p9rdr.sys | 10.0.26100.9444 | 10.0.26100.8972 |
| vmbusr.sys | 10.0.26100.1 (written 08 Sep 20:57) | 10.0.26100.1 (11 Aug build) |

vmbusr.sys was replaced by the KB — the timestamp changed — but it carries the same file version before and after, so the version alone does not tell whether the binary changed. I did not hash it before uninstalling, so I cannot confirm that either way.

Happy to reinstall the KB and capture anything specific if it helps.

Independent confirmation on a second x64 machine. Same failure, same binary
versions, and I can add a precise before/after timestamp from the host log.

System

• Windows 11 25H2, build 26200.9445
• Claude Desktop 1.49585.0
• KB5124008 reported by Get-HotFix as installed 2026-09-10
• KB5126052 (.NET Framework 3.5/4.8.1) installed the same day — ruled out

Binary versions after the update (identical to the original report)

| File | Version | LastWriteTime |
|---|---|---|
| p9rdr.sys | 10.0.26100.9444 | 2026-09-08 21:46:42 |
| p9np.dll | 10.0.26100.9278 | 2026-09-02 11:27:23 |
| vmcompute.exe | 10.0.26100.8875 | 2026-09-08 21:46:38 |
| vmwp.exe | 10.0.26100.8875 | 2026-09-02 11:27:15 |

Exact moment it broke, from %LOCALAPPDATA%\Claude\logs\cowork_vm_node.log:

2026-09-10 08:48:37 [info] [VM:steps] add_plan9_shares completed (74ms)
2026-09-10 10:12:14 [warn] [vm-stderr oneshot-] sandbox-helper: no Plan9 drive
                            shares mounted under /mnt/.virtiofs-root/shared

Every VM start from 09-06 through 09-10 08:48 completed normally. Every start
after 10:12 fails, and it has failed on every start since.

Worth noting: the two files that matter carry a LastWriteTime of 09-08
21:46, two days before Get-HotFix dates the KB. So the payload is staged
early and it is the restart that arms it — which means the correlation is
with the reboot, not with the install date users see. That may explain why
some people report the break on a different day than the one Windows Update
shows them.

Silent failure, confirmed here too: the host side logs
add_plan9_shares completed with no error and no HRESULT on every single
failing start (09-10 10:47, 11:03, and after). Nothing in the host log says
zero shares were attached. If add_plan9_shares returned an error when it
attaches 0 of N, this would have been diagnosable in minutes instead of days.

I have not uninstalled the KB (production machine, September security
patches), so I can't offer an A/B rollback — but everything up to that point
matches #92984 exactly.

Separate, pre-existing issue that survives this one: with mapped SMB
network drives as connected folders, device_list_dir works fine while
device_stage_files fails with Could not stat <drive>:\<path> on the very
same file in the very same session, and UNC paths are rejected outright with
UNC paths are not allowed. That behaviour predates KB5124008 and is
unaffected by it — filed already as #54069 / #41687, mentioning it here only
so it isn't mistaken for part of this regression.

Confirming this on Windows 11 Home (original report is Pro). Same KB, same UBR, same failure mode.

Environment

• Windows 11 Home, 10.0.26200 (25H2), x64 — UBR 9445
• KB5124008, InstalledOn 2026-09-09, InstalledBy NT AUTHORITY\SYSTEM
• Claude Desktop MSIX install (Claude_pzs8sxrjxfjjc)

Cowork had worked for months on this machine with no configuration changes. It broke immediately after KB5124008 installed on 2026-09-09.

The first symptom surfaced in the app as a workspace-service error, and CoworkVMService was indeed stopped. Start-Service CoworkVMService succeeds and the VM then boots and answers RPC, but every host share fails to mount:

resume: 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/<ids>/outputs as outputs:
source path ... is under Plan9 share "c" which is not mounted;
create: RPC error -1: ensure user: user <session-user> already exists unexpectedly: uid=1150 gid=1150

Identical on every retry and identical in a brand-new conversation, so it is not stale session state.

Ruled out here as well: Start-Service / Restart-Service CoworkVMService, full quit of Claude Desktop including the tray icon, a full Windows restart, and a fresh session. I also chased the OneDrive hypothesis (#25293) before finding this issue — worth underlining OP's finding that a plain local NTFS folder fails identically, so the Cloud Files filter driver is a red herring for this regression.

Two UX points that cost me an hour each:

1. The in-app error text says to restart the computer. For this cause a restart cannot possibly help, and it sends users straight down a dead end. Detecting UBR 9445 and saying so would save a lot of time.

1. Set-Service CoworkVMService -StartupType Automatic fails with PermissionDenied / "Access denied" even from an elevated administrator PowerShell:

Set-Service : Service 'Claude (CoworkVMService)' cannot be configured due to the following error: Access denied
FullyQualifiedErrorId : CouldNotSetService,Microsoft.PowerShell.Commands.SetServiceCommand

The service's security descriptor denies configuration changes to local administrators, so the Set-Service mitigation circulating for the adjacent "service not running" cluster (#36590, #64592) cannot be applied at all. Unrelated to this KB regression, but it blocks the documented workaround for that one.

On mitigation: asking users to uninstall a September security update is rough, particularly on Home editions where update deferral is capped and the KB simply reinstalls itself. An app-side fallback — retrying with virtiofs when the 9p mount returns EINVAL instead of treating it as fatal — would restore the sandbox without anyone having to drop a security patch.

Two additions, both prompted by the comments above.

A mitigation that works where deferral doesn't. @FRGOMES1987 is right that uninstalling is rough and that on Home the KB simply comes back — deferral is capped and the pause UI may be policy-disabled. It is here too, and Windows Update started re-downloading KB5124008 within minutes of the post-uninstall reboot. What does work, on any edition and regardless of update policy, is hiding the update in the Windows Update agent itself — what wushowhide.diagcab did, callable directly, no third-party module:

Stop-Service bits -Force          # stops an in-flight download
Start-Service wuauserv
$s = New-Object -ComObject Microsoft.Update.Session
$r = $s.CreateUpdateSearcher().Search("IsInstalled=0 and Type='Software'")
$u = $r.Updates | Where-Object { $_.KBArticleIDs -contains '5124008' }
$u.IsHidden = $true
Start-Service bits

It survives reboots and it is per-update, so the rest of the patch stream keeps flowing. Still a workaround with an expiry date — re-check it, since anything that resets the update agent clears the flag — but it beats blanket-pausing or staying unpatched wholesale.

One caveat on the install-vs-reboot theory. @CSN1993's evidence for "the reboot arms it" is good: VM starts kept succeeding for two days with the new binaries already on disk. But the premise that Get-HotFix lags the binary timestamps is not universal — here Get-HotFix reports KB5124008 installed 2026-09-08 and the binaries were written 2026-09-08 20:57–20:59, the same day. And my own case cannot discriminate between the two hypotheses at all: no VM started between the binaries landing at 20:57 and the reboot, so I have no observation in that window. Worth saying out loud so the two-day offset isn't generalised into a diagnostic rule.

Also confirming, since it came up: CoworkVMService refuses configuration changes to local administrators here as well. It logs failed to configure SCM recovery actions ... Access denied on every start, going back months in the event log — so that is how the service ships, not something a local policy did. The practical consequence beyond blocking the Set-Service workaround: if the service ever crashes, it will not restart until the machine reboots, which on an unattended box is a silent outage.

Confirmation on a second machine — x64, Windows 11 25H2 (build 26200.9445)

Same failure as reported, on a different machine and a different Windows edition
line than the original report. Posting the numbers in case they help narrow it.

Environment

| Item | Value |
|---|---|
| Claude Desktop | 1.49585.0 |
| OS | Windows 11 Pro, DisplayVersion 25H2, build 26200.9445 (ProductName string still reads "Windows 10 Pro") |
| Arch | x64 |
| Electron / Node | 44.2.0 / 24.20.0 |

Symptom

Every device_bash call fails immediately:

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

with the note that all connected folders "failed to mount and cannot be reached
from this shell". The VM itself is up — RPC works, and the non-shell bridge tools
still respond: device_list_dir lists connected folders normally, and
device_stage_files / device_commit_files work against local disk paths.

Anything on a mapped network drive (Z: → \\SERVER\SHARE) is unreachable,
because device_bash was the only working path for it here:
device_stage_files has never worked on Z: ("Could not stat"), and
device_commit_files to Z: fails with "fetch or write failed".

Update history

KB5124008 was installed on this machine on 2026-09-09, the same day the
sandbox stopped mounting. Installed that day:

KB5124008  Security Update  09/09/2026
KB5124007  Security Update  09/09/2026
KB5126052  Update           09/09/2026

Previous update was KB5120997 on 28/08/2026, and the sandbox was working
normally through the morning of 09/09 — a device_bash job wrote six files to
the Z: drive at 07:16 local time, and by ~10:00 local nothing mounted.

Plan9 / Hyper-V component versions after the update

p9rdr.sys           10.0.26100.9444
p9np.dll            10.0.26100.9278
computestorage.dll  10.0.26100.9444
vmcompute.exe       10.0.26100.8875
vmwp.exe            10.0.26100.8875

These match the versions listed in the original report exactly.

Tried, did not help

• Full Windows restart
• Disconnecting and re-adding the connected folders (4x)
• Connecting an additional, local-disk folder — still 0 shares mounted
• UNC path instead of the mapped drive letter — refused by the connector itself

(UNC paths are not allowed)

Workaround in use

Not uninstalling the security update. Files are shuttled to and from the network
drive by a PowerShell script that the user launches manually, since the Windows
shell still sees the mapped drive without any problem — the copy is verified by
SHA-256 on both ends. It works, but it costs a manual double-click per cycle and
it only covers file transport; nothing else device_bash did is recoverable
this way.

A clearer guest-side error naming the Plan9 change would have saved several hours
of chasing the mapped drive and the network share, which turned out to be
innocent.

A workaround that keeps Cowork usable without uninstalling KB5124008

Confirming the regression on one more machine — Windows 11 Pro 25H2, build
26200.9445, x64, Claude Desktop 1.49585.0, KB5124008/KB5124007/KB5126052 all
installed 2026-09-09, same mounted 0/N signature. That is already well
established in this thread, so I will keep the confirmation to one line and
spend the rest on something I have not seen described here: a way to keep
working that survives a reboot and needs no human action, and two traps that
cost me time getting there.

First, an important limit on the "the bridge still works" workaround

Several comments note that device_list_dir / device_stage_files /
device_commit_files keep working, so files can be staged into the cloud
container and committed back. True — but only for local disk.

On a mapped network drive (Z: → \\SERVER\SHARE) the bridge is not a
workaround at all:

| Operation | On local disk | On a mapped network drive |
|---|---|---|
| device_list_dir | works | works |
| device_stage_files | works | fails: Could not stat |
| device_commit_files | works | fails: fetch or write failed |

device_stage_files has never worked on mapped drives here — that predates
this regression. Which means device_bash was the only path to a network
drive, and with it gone the drive is reduced to a directory listing. Anyone
whose work lives on a file server (the OP shares 8 mapped drives into the VM)
gets nothing from the staging workaround.

Two related traps worth flagging, since both cost me a wrong conclusion:

• Could not stat is returned **identically for a file that exists and one

that does not**, so it cannot be used to check whether a file arrived.

• device_list_dir caps at 2000 entries, so on a large folder the file you are

looking for may simply be past the cut.

Verification of anything on a network drive therefore has to be done by the
Windows side, not through the bridge.

The workaround: let Windows do the part the guest can't

The host shell still sees the mapped drive perfectly. So the transport moves
there: a small PowerShell script in a local folder (one the bridge can
still read and write), driven by two plain text manifests.

_PONTE\
   pedidos.txt     lines: full source path on Z:      -> copied into _ENTRADA
   _ENTRADA\       files pulled off the network drive, now bridge-readable
   _SAIDA\         files to deliver
   entregas.txt    lines: filename | full destination path on Z:
   _log_ponte.txt  result of every transfer
   _heartbeat.txt  rewritten every run, even when idle

The assistant writes the manifests through the bridge (local folder, so this
still works), the script does the copy on the Windows side, and the assistant
reads _log_ponte.txt back through the bridge. The loop closes without the
guest mount ever being involved.

What made it trustworthy rather than a hack:

• SHA-256 compared on both ends of every copy; on mismatch the copy is

deleted and the line is logged as failed. Network-drive writes can "succeed"
and leave a truncated file.

• Destination whitelist — the script refuses any path outside two named

folders, regardless of what the manifest says.

• No silent overwrite: an existing destination file is skipped unless the

line explicitly ends with an override keyword.

• Successful lines are consumed and archived with a timestamp, so a

2-minute schedule does not redo the same transfer forever.

• _heartbeat.txt rewritten on every run, including idle ones. This is what

lets the assistant tell "nothing to do" apart from "the shuttle is dead" —
and the log stays quiet, since nothing is written when there is no work.

• A PAUSAR.txt file in the folder halts it instantly, without touching Task

Scheduler.

Driven by a Task Scheduler entry every 2 minutes, this is fully unattended:
routines that generate files on the network drive run end to end again, with
the security update still installed.

Two Task Scheduler traps

Both of these produced a task that looked healthy and did nothing:

1. **A LogonTrigger with a Repetition block never starts if the user is

already logged on.** The task exists, runs fine on a manual schtasks /run,
and never repeats — the repetition is anchored to a trigger that already
fired. Use a daily CalendarTrigger with the repetition attached, which is
active from the moment it is created. "The task was created" and even "the
task ran once" prove nothing; the only real test is watching the heartbeat
file advance on its own.

1. Creating the task needs elevation — the definition is written under

C:\Windows\System32\Tasks. Without it schtasks /create returns
Acesso negado / access denied after the confirmation prompt.

Also worth knowing: the task must run as the interactive user, because a
mapped drive letter only exists inside that user's session. A task running as
SYSTEM cannot see Z: at all. That caps the autonomy — the machine has to be
logged on — but it is the same constraint the work already had.

Unrelated observation, in case it is a separate defect

Twice in one session device_commit_files returned {"written":[...],
"rejected":[]} while the file on disk kept its previous content and size. Both
times it was a re-write of a path already committed earlier in the same
session; committing identical bytes from a differently-named container file
to the same destination worked immediately. Comparing size or hash after every
commit is the only way I found to catch it, and a success response that does not
write is a bad failure mode for exactly the workaround this thread is relying
on. Happy to open this separately if it is not already known.

On the rollback

The A/B narrowing to p9rdr.sys / p9np.dll in this thread is convincing, and
uninstalling clearly works. I have deliberately not done it: KB5124008 carries
fixes for actively exploited elevation-of-privilege vulnerabilities, and the
machine is the bridge to a company file server. The point of the shuttle above
is to make "stay patched and keep working" a real option while a Cowork-side
fix is worked out.

Happy to share the script if it would help anyone.

Same failure here, independent confirmation.

Environment

• Windows 11 Pro, build 26200 (25H2), Dell Vostro 5620, x64
• KB5124008 installed 2026-09-08 (also KB5124007 and KB5126052 same day)
• Claude Desktop 1.49585.0 (Electron 44.2.0, Node 24.20.0)
• Windows Defender only, no third-party AV

Symptom

Every device_bash call fails before the command runs, with:

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

The VM itself boots fine — the error is produced by the helper running inside the guest, so the guest is alive; it just receives no shares. Started around 2026-09-08 and has been continuous since.

Additional data point: not a folder or path issue

I connected a second, freshly created folder with a trivial path (C:\Temp\Prova, no spaces, no parentheses, not synced to any cloud storage). Both folders fail identically — the shell reports mnt/MAIN_ClaudeCode, mnt/Prova failed to mount. So this is not specific to one folder, one path shape, or OneDrive.

Additional data point: WSL is not installed at all

Unlike the original report, this machine has no WSL: Microsoft-Windows-Subsystem-Linux is disabled, LxssManager and WslService do not exist, wsl --status reports it as not installed. Cowork worked normally on this machine before KB5124008, so the Plan9 share path here never depended on WSL being present.

Virtualization state (measured after the failure)

• HyperVisorPresent: True, System log shows "Hypervisor successfully started" on every boot
• VirtualMachinePlatform: enabled (InstallState 1)
• vmcompute: Running — HvHost: Running
• Full Hyper-V role not installed (Microsoft-Hyper-V* InstallState 2), vmms does not exist — this is the machine's normal, pre-existing configuration
• VMware Workstation drivers are present on this machine (vmx86, VMnetBridge, VMnetAdapter), and were present before the failure too

Tried, no effect

• Multiple full power cycles over two days
• Reconnecting existing folders, connecting a new one
• Full uninstall/reinstall of Claude Desktop — reinstall produced the same version 1.49585.0, and the error is byte-for-byte identical
• Reboot after the reinstall (in case new drivers or services needed a restart)

Not tried

Uninstalling KB5124008. This is a company-managed machine and that update carries roughly 1000 security fixes including two zero-days, so removing it is not an option here. I can confirm the failure state and run diagnostics on request, but I cannot A/B test the rollback.

Happy to provide any additional logs or output that would help.

Confirming this on x64. Windows 11 Home 25H2, build 26200.9445, Claude Desktop 1.49585.0 — same desktop build as the original report. Sandbox failed on every bash call with source path ... is under Plan9 share "c" which is not mounted, across six sessions over two days. Uninstalling KB5124008 and rebooting restored it immediately, with no other changes. The failure began the same day the update installed.

Second confirmed case, same fault and same fix.

Setup: Windows 11 Pro 25H2, build 26200.9445 after KB5124008 (and KB5126052 .NET) installed on 9 September 2026. Claude Desktop MSIX build (package Claude_pzs8sxrjxfjjc), version 1.49585.0 (41ad1d), the same as the original report.

Symptoms: from 9 September every Cowork scheduled task that needs the sandbox failed at start with sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared. The VM started, file staging and commit still worked, but device_bash could not run at all. Three consecutive days of morning runs failed the same way.

What did not help: relaunching the app, a full Windows reboot, "Free Up Cowork Disk Space" (reported nothing to free), and "Delete Cowork VM Sessions and Restart", which itself failed with EACCES: permission denied, unlink 'C:\Users\HP\AppData\Roaming\Claude\local-agent-mode-sessions\<id>\latest'. That path does not exist in Explorer or PowerShell (the real data sits under the package's LocalCache\Roaming redirect, and there is no latest entry there either), so the sessions cleanup looks broken on the MSIX build as well.

Fix: wusa /uninstall /kb:5124008, reboot. Plan9 shares mounted immediately and device_bash worked on the first call. Windows Update is paused to stop the KB reinstalling.

Happy to send a diagnostic report or VM debug logs if useful.

### Warning: the wusa /uninstall /kb:5124008 workaround left my machine unbootable.

Same symptom as OP — Cowork on Windows 11 25H2 (26200.9445), all Plan9 shares failing after KB5124008. I tried the documented workaround and it did not work for me.

Sequence:
Ran the uninstall, waited for Windows to prompt for the reboot, rebooted when asked. No forced power-off, no interruption.
Machine came back to Recovery — Your PC/Device needs to be repaired, error 0xc0000428, "The digital signature for this file couldn't be verified."
WinRE (F1) looped back to the same screen every time. Safe Mode, Safe Mode with Command Prompt, and Lenovo F11 recovery all failed the same way. "Repair my PC" from Windows install USB restarted back into the broken internal boot rather than handing off to WinRE.
Lenovo UEFI diagnostics passed every storage test, so this was purely a servicing/boot failure, not hardware.
Recovery, for anyone who lands here:
Boot the Windows 11 install USB, press Shift+F10 at the language screen for a command prompt (the "Repair my PC" path was broken for me).
dism /image:C:\ /cleanup-image /revertpendingactions — reported pending actions to revert, deferred to next boot.
That changed the error to 0xc0000098 (BCD doesn't contain valid information).
diskpart → assign a letter to the 100MB EFI partition → bcdboot C:\Windows /s S: /f UEFI.
Reboot → "Something didn't go as planned, undoing changes" → booted to desktop.
Note the outcome: revertpendingactions undid the pending uninstall, so I came back up with KB5124008 still installed (26200.9445) and Cowork still broken. Net result of the workaround was several hours of recovery and no fix.
Worth flagging in the issue body that the uninstall carries real risk — the machine may not come back. Given KB5124008 is a security update, a Cowork-side fix seems like the only reasonable path.
Environment: Lenovo ThinkPad E16, Core Ultra 7 155U, Windows 11 Pro 25H2 (26200.9445), UEFI-only BIOS (no CSM), Secure Boot off.

Was really hopeful the rollback would get me back online with Cowork as I have a handful of deliverables at work that I've developed complex projects for.

I'm considering trying the rollback again (after backing up my disk, that was scary), just in case the failure was some anomaly, but may give it a few days and see if Anthropic comes to the rescue here.

Going to see what I can accomplish in the meantime with Claude Code or just Chat, as I've been meticulous about saving my specs and scripts on my local disk that can be easily referenced in other sessions if needed.

Despite the rollback not working for me, this thread has helped tremendously, I am somewhat relieved to not be experiencing this frustration alone. Godspeed.

Second repro, x64.

Environment

Windows 11 24H2 x64, build 26200.9445, KB5124008 installed 2026-09-10
Claude desktop 1.49585.0 (Electron 44.2.0), claude-code 2.1.260
Worked for months. Started failing between the evening of 2026-09-09 and the early hours of 2026-09-10, matching the update.

Symptom, verbatim

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

Additional negative results not in the original report

Each done separately, with all Claude processes ended first. None changed the outcome:

Windows reboot.
Full app stop and restart.
Renamed %APPDATA%\Claude\vm_bundles\claudevm.bundle. The app downloaded a fresh 9.2 GB bundle. No change.
Full uninstall, then clean install of the current build from claude.ai/download. No change.
Renamed %APPDATA%\Claude to force a clean profile: fresh sign-in, connected folder re-granted before the VM booted. No change.

So a corrupt VM image, a corrupt install and a corrupt app profile are all ruled out.

One possibly useful signal

During step 3, while the replacement bundle was still downloading, the error changed to:

Workspace unavailable. The isolated Linux environment on this device failed to start.

Once the new bundle was in place it reverted to the Plan9 message. So the VM itself boots; only the share attach fails.

Still working on the same machine, throughout the outage

device_list_dir / device_stage_files / device_commit_files all fine
WSL2 fine: podman machine init and podman machine start created and ran a WSL2 machine during the outage
Claude Code in the desktop app unaffected

Not tested: uninstalling KB5124008. Staying patched for now.

Same symptom here on x64, independently reproduced.

Environment

• Claude Desktop 1.49585.0, Windows 11 x64
• Connected folder: a plain local NTFS path (not OneDrive-synced)
• Onset: immediately after installing KB5124008 on 2026-09-10. Worked fine on the same app version before the update.

Error — every device_bash call fails with:

sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
[Note: mnt/<folder> failed to mount and cannot be reached from this shell.]

Additional data point on HypervisorPlatform

The original report lists HypervisorPlatform disabled. In my case HypervisorPlatform is enabled, and the failure is identical. So the Windows Hypervisor Platform optional feature can be ruled out as a factor in either direction.

Also tried, no effect

• App restart, full OS reboot (multiple times)
• Claude Desktop repair install
• Claude Desktop full uninstall + reinstall
• WSL update (unrelated, as expected — WSL2 drvfs keeps working here too)

Scope of impact

Worth noting for triage: the file bridge (device_list_dir / device_stage_files / device_commit_files) still works fine — I can read and write the same folder without issue. Only the in-VM Plan9 mount is broken, so the blast radius is device_bash (local command execution) rather than file access.

On the error message

+1 to the request for a better error. Because add_plan9_shares reports completed with 0 shares attached, the only thing a user sees is the in-guest "no Plan9 drive shares mounted" message, which points at nothing. I spent hours on repair installs and reinstalls before finding this issue. Surfacing the 0-share condition host-side would have saved all of it.

Same regression, same build (25H2, 10.0.26200.9445), but the documented
workaround is not available on this machine — worth noting since the issue
currently reads as "user has a workaround."

wusa:
wusa /uninstall /kb:5124008
→ Windows Update Standalone Installer: "Installer encountered an error: 0x800f0926"

Expected, since KB5124008 is a combined SSU+LCU and wusa can't remove a
package containing the SSU. So I used the documented DISM path instead:

DISM /Online /Get-Packages /Format:Table | findstr RollupFix
Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10 | Staged | Security Update |
Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.8875.1.28 | Superseded | Security Update | 7/15/2026
Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9168.1.19 | Superseded | Security Update | 8/13/2026
Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26 | Installed | Security Update | 9/9/2026

DISM /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26
→ An error occurred - Package_for_RollupFix Error: 0x800f0926
→ DISM failed. No operation was performed.

So on this machine the LCU is not removable by either supported method, and
rolling back is not an option at all. KB5124008 closes 628 CVEs including at
least one on CISA KEV, so staying unpatched wouldn't be acceptable here even
if removal did succeed.

This needs a Cowork-side fix rather than a rollback workaround. Happy to run
diagnostics on a machine that is stuck in the broken state.

Confirming on Windows 11 Home 25H2 x64. Staying on KB5124008, so no rollback data from me.

• Windows 11 Home 25H2, build 26200.9445 (KB5124008 + KB5124007 + KB5126052), x64
• Claude Desktop 1.49585.0.0 (MSIX), VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62, SDK 2.1.260
• Timeline (local): 9 Sep 20:57 last working bash (bash done: exit=0), already on 1.49585.0.0. 10 Sep 02:35 Setup event: "Package KB5124008 was successfully changed to the Installed state." 10 Sep 07:16 first bash after the first VM boot since then: failed. Every call since fails.

Host (cowork-service.log), first boot after the install:

[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.
[VM] VM started successfully

App (main.log):

RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/<path> as <mount>: source path <path> is under Plan9 share "c" which is not mounted

Guest log: nothing to quote. coworkd\user-<SID>.log stopped growing at 105,699,251 bytes (just over 100 MiB) on 9 Sep, before the KB took effect, even though every later boot logs Starting daemon console reader ... log=...user-<SID>.log. Possibly a size cap on the console log. Worth checking, since it hides the mount result.

File versions: vmcompute.exe 10.0.26100.9444, vmwp.exe 9278, computestorage.dll 9444, p9rdr.sys 9444, p9np.dll 9278, vmbusr.sys 9278, vp9fs.dll 9278.

DISM: Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26 shows PSFXDeltaFormat : ForwardOnly on this updated (not clean-media) install. Removal not attempted; KB5124008 fixes CVE-2026-81963 (exploited).

Cowork (Windows x64): KB5124008 breaks all Plan9 shares — and on this machine the KB is a PERMANENT package that CANNOT be uninstalled (DISM 0x800f0926 container dependency)
This is a follow-up data point to #92984. Same root cause (KB5124008 breaks Cowork's Plan9 mount), but with an important new finding: the recommended workaround — "uninstall KB5124008" — does not work on every affected machine. On mine the update is a permanent / checkpoint package with a container dependency, so both wusa and online DISM /remove-package refuse to remove it. That means affected users on checkpoint-baselined builds have no self-service recovery and need an app-side fix.
Symptom
Every device_bash call (and any sandbox shell use) fails immediately with:

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

Connected folders (2Q26 財報, 台股 Mimi 版本, Mimi 交易篇, LS 書摘) all report "failed to mount and cannot be reached from this shell." The file bridge tools (device_list_dir, device_stage_files, device_commit_files) still work — only the Plan9-mounted shell is dead.
Environment (from get_device_info)
Claude Desktop appVersion: 1.49585.0 (electron 44.2.0, node 24.20.0)
Platform: win32 / x64
Windows image version: 10.0.26200.9445
Servicing stack: 10.0.26100.9441
Installed update: KB5124008 (confirmed via Get-HotFix → Win32_QuickFixEngineering HotFixID="KB5124008")
Confirmed: multiple full reboots do NOT fix it
Rebooted many times, re-checked connected folders, restarted the app — the Plan9 mount never comes back while KB5124008 is installed. (Consistent with #92984.)
New finding: the KB cannot be uninstalled on this machine
Elevated attempts:

wusa /uninstall /kb:5124008 → fails.
DISM /online /remove-package /packagename:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26
Processes to 100%, then fails with 0x800f0926.

C:\Windows\Logs\DISM\dism.log states the cause explicitly:

Package Package_for_RollupFix~...~26100.9445.1.26 with CBS state 7(CbsInstallStateInstalled) ...

Error in operation: Package cannot be uninstalled due to container dependency. (CBS HRESULT=0x800f0926)

Failed finalizing changes. (hr:0x800f0926)

Permanent package cannot be uninstalled due to container dependency.

DISM.EXE: Image session has been closed. Reboot required=no.

So on checkpoint-cumulative-update builds where KB5124008 has become a permanent baseline with a dependent container, the documented workaround is a dead end. Remaining options for the user are all heavy: WinRE offline uninstall, in-place repair install with an older ISO, or system restore.
Impact
Cowork sandbox shell is completely unusable on affected x64 machines.
The only official workaround (uninstall the KB) is impossible on checkpoint-baselined machines.
WSL2 drvfs reportedly still works (per #92984), so the break is specific to Cowork's token-based 9p implementation, not the host's 9p stack in general.
Ask
An app-side fix (or updated sandbox-helper mount handshake compatible with the post-KB5124008 Hyper-V/Plan9 components: vmcompute.exe, vmwp.exe, p9rdr.sys, p9np.dll, computestorage.dll) is needed, because KB uninstall is not available to all a

I'm having the same issue.

<html>
<body>
<!--StartFragment--><p dir="ltr"><strong>Confirming on x64 with a clean A/B rollback - KB5124008 is the trigger</strong></p>
<p dir="ltr">Same root cause here, x64 (not ARM64), reproduced and resolved today.</p>
<p dir="ltr"><strong>Environment (identical in both states):</strong></p>
<div dir="ltr">
  |  
-- | --
Claude Desktop | 1.49585.0 (MSIX, Claude_pzs8sxrjxfjjc)
Electron / Node | 44.2.0 / 24.20.0
OS | Windows 11 x64, 24H2

</div>
<p dir="ltr"><strong>Symptom on 9445</strong> - every Cowork session died instantly at startup with:</p>
<div><div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/&lt;user&gt;/AppData/Local/
Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/
&lt;session-id&gt;/.claude as .claude: source path ... is under Plan9 share "c" which is not mounted</code></pre></div></div></div>
<p dir="ltr">Note it fails on the app's <strong>own</strong> session directory - so it is not folder-specific. No connected folder was involved; there was nothing a user could reconfigure to work around it.</p>
<p dir="ltr"><strong>What did NOT help</strong> (all tried before the rollback):</p>
<ul dir="ltr">
<li>multiple full reboots</li>
<li>restarting <code>CoworkVMService</code>, <code>vmcompute</code>, <code>vmms</code></li>
<li>killing all Claude/Cowork processes</li>
<li>removing and re-adding connected folders</li>
</ul>
<p dir="ltr"><strong>What fixed it:</strong></p>
<div><div role="group" aria-label="powershell code" tabindex="0"><div><div></div></div><div>powershell</div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code class="language-powershell" style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre;"><span><span>wusa /uninstall /kb:<span style="color: rgb(94, 237, 237);">5124008</span> /norestart</span></span></code></pre></div></div></div>
<p dir="ltr">Reboot → UBR dropped <code>9445</code> → <code>9278</code>, <code>Get-HotFix -Id KB5124008</code> returns <em>not found</em>, and Cowork came up on the first try. Existing sessions were intact on disk the whole time - only the VM could not mount them.</p>
<p dir="ltr">Verified post-fix from inside the guest: connected folder mounts correctly under <code>~/mnt/&lt;folder&gt;</code> and <code>device_bash</code> responds normally. Both of those were completely dead on 9445.</p>
<p dir="ltr">So this is <strong>not</strong> ARM64-specific - x64 <code>26200.9445</code> is affected the same way, and the guest-side symptom matches #92958's description exactly. Worth noting the failure mode is silent host-side: the share attach reports success while the guest gets nothing.</p>
<p dir="ltr">Would be good to get a guard in the client - even just detecting "0 shares mounted" and surfacing "Windows update KB5124008 breaks the Cowork VM, roll it back" instead of a raw RPC error. Right now the error text points users at their own folders, which is exactly the wrong place to look.</p>
<!--EndFragment-->
</body>
</html>

Just putting this out there:

Swap one file: C:\Windows\System32\vp9fs.dll, the host-side Plan9 server.
In place now 10.0.26100.9278, written 9/9/2026 1:31 AM by KB5124008, 71ce254f2025bef5
Roll back to 10.0.26100.8972, b6a44ae59bb5ebad
Source Already on your disk: C:\Windows\WinSxS\amd64_hyperv-{i-feel-like-sharing-this-hash-is-a-noob-move}4e35_10.0.26100.8972_none_9a0449b9c451dade\
Both confirmed present just now. .8972 is the version that ran from August 11 through September 8 -- exactly your known-good window. Only 131 bytes of executable code separate the two.

Of course, it's a security rollback of what I can only presume is some sort of attack surface... AND there's no guarantee it survives a computer reboot.

I'm not doing it, but it came up when I was trying to figure it out and I thought I'd add to the conversation.

Me too

Anthropic has now acknowledged this on their status page (2026-09-10, 15:54 UTC): "Degraded functionality for Claude Cowork on Windows" — cause identified as a change in Windows from the September 8 update; "Microsoft has developed a fix and is working on releasing it"; no in-app workaround; restarting or reinstalling won't help. https://stspg.io/5yp3rhhztm30

Confirming the same root cause and the same fix on another x64 machine:

• Claude Desktop 1.49585.0 (MSIX/Store), Windows 11 25H2 build 26200, Hyper-V, Intel Core Ultra 7 155H. No WSL distro installed.
• Timeline (2026-09-09, UTC-3): KB5124008 + KB5124007 + KB5126052 installed; two reboots at 22:07 and 23:03 (cumulative, then the Secure Boot certificate restart). From 23:16 every device_bash call fails with sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared. Hyper-V Worker/Compute/VmSwitch event logs show zero errors on the host.
• Did not help: app restart, three Windows restarts, MSIX Repair, full VM bundle reset (renamed claudevm.bundle; fresh 1.29 GB rootfs.vhdx.zst downloaded; identical failure on the first cold boot). Note that the app's own auto-reinstall never replaces rootfs.vhdx because its running VM keeps it locked (EBUSY) — the bundle has to be renamed with the VM stopped.
• Fixed immediately: wusa /uninstall /kb:5124008 + reboot. Windows Update paused afterwards.

I opened #93242 before finding this issue; it can be closed as a duplicate of this one.

Confirming this on two separate machines, both Windows 11 Pro build 26200. 9445, MSIX package Claude_pzs8sxrjxfjjc, Claude Desktop 1.49585.0.0, same corporate tenant. Tried two different models — no difference, as expected for an infrastructure issue.

Get-HotFix confirms KB5124008 installed by NT AUTHORITY\SYSTEM on 2026-09-10 — the same day Cowork stopped working on both machines. No other change on either: no Claude update, no antivirus or policy change, no user-installed software.

Symptom matches the original report. The VM boots, connected folders attach successfully at the app level, but every bash call fails at startup:

RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/<redacted>/AppData/Local/Packages/
Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/<...>/outputs as outputs:
source path ... is under Plan9 share "c" which is not mounted;
create: RPC error -1: ensure user: user <redacted> already exists unexpectedly: uid=1077 gid=1077

It fails mounting Claude's own outputs and uploads directories, before any user folder is involved.

Did not help:

Ending every Claude.exe in Task Manager, then relaunching
Full Windows restart (not fast-startup shutdown)
Reconnecting the folder
Moving the working folder off a mapped SMB network drive (Z:) to a plain local NTFS path under C:\Users\<redacted>\Downloads — failed identically, so this is not network-drive or cloud-sync specific
App Repair — worth noting Repair silently refuses while Claude is running, which is easy to miss since you're usually reading the instructions in Claude

Second machine rules out local corruption. Adding an independent data point to help prioritise; happy to supply guest/host logs.

Anthropic has an open incident now [https://status.claude.com/incidents/r1pqn1kb4hvk](url)

Scope, which may matter for triage: the failure is confined to the in-VM
shell. device_list_dir, device_stage_files and device_commit_files all keep
working normally, at any folder depth — I did a full multi-file read/edit/write
cycle against the connected folders while the shell was down. So the Plan9 share
path is broken while the file-transfer path is untouched; the only lost
capability is running processes on the machine.

Also failed here, matching the original report: reboots, removing and
re-adding the connected folders, and updating the app (already newest).

A/B rollback — confirmed fix. Removed the LCU and rebooted; all mounts
returned immediately, with read access inside both folders.

Get-WindowsPackage -Online | Where-Object PackageName -like "*RollupFix*" |
  Sort-Object InstallTime -Descending |
  Select-Object -First 5 PackageName, PackageState, InstallTime

Remove-WindowsPackage -Online -PackageName `
  "Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26"

Post-removal build: 26200.9168.

Two notes for anyone else reproducing this:

1. The package name carries the build, not the KB number — it reads

26100.9445 even though the reported build is 26200.9445 (24H2/25H2 share
the 26100 servicing base; 26200 comes from the enablement package). Searching
the package list for "5124008" or "26200" finds nothing. Match on the UBR plus
InstallTime, and remove only the entry whose PackageState is Installed.

1. [System.Environment]::OSVersion.Version does not expose the UBR — it

returns Revision 0, so it reports 10.0.26200 and never .9445. Read the
UBR from the registry before uninstalling, since it changes afterwards.

Microsoft's KB5124008 page carries no known-issues entry for Hyper-V or
virtualization, so this seems unlikely to surface from their side without
reports.

Same issue here, plus a data point for anyone whose uninstall fails with 0x800f0825.

Environment: Windows 11 x64, build 26200.9445, Claude Desktop 1.49585.0. KB5124008 and KB5126052 (.NET) were installed together at 04:25 local time on 2026-09-10; from the first Cowork attempt after that, mounts failed with no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared, with p9rdr.sys at 10.0.26100.9444. KB5124007 (installed 2026-09-08) had worked for two days.

Uninstall blocked: wusa /uninstall /kb:5124008, Settings > Uninstall updates, and DISM /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26 all failed with 0x800f0825 (dism.log says "Permanent package cannot be uninstalled"). CBS.log has the actual reason:

Capability: RetailDemo.OfflineContent.Content~~~~0.0.1.0 must be uninstalled first. The RTM version is missing. [HRESULT = 0x800f0825 - CBS_E_CANNOT_REMOVE]
Capability: RetailDemo.OfflineContent.Content~~~pt-BR~0.0.1.0 must be uninstalled first. The RTM version is missing. [HRESULT = 0x800f0825 - CBS_E_CANNOT_REMOVE]
Failed verifying that the target package: Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9278.1.35 has a full set of required FODs/LPs

DISM /Online /Remove-Capability with those names returns error 1168 (element not found): the capability is not registered, but its packages are. Get-WindowsPackage -Online | Where-Object PackageName -like '*RetailDemo*' listed Microsoft-Windows-RetailDemo-OfflineContent-Content-Package~31bf3856ad364e35~amd64~~10.0.26100.9444 and the -pt-br- one, both Installed.

What worked:

1. Pause Windows Update.
2. Remove the language package first, then the neutral one (take the exact names from your own list; the language tag will differ):

``
DISM /Online /Remove-Package /PackageName:Microsoft-Windows-RetailDemo-OfflineContent-Content-pt-br-Package~31bf3856ad364e35~amd64~~10.0.26100.9444
DISM /Online /Remove-Package /PackageName:Microsoft-Windows-RetailDemo-OfflineContent-Content-Package~31bf3856ad364e35~amd64~~10.0.26100.9444
``

1. Remove the LCU again:

``
DISM /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26
``

1. Reboot.

After that, p9rdr.sys is back at 10.0.26100.9278 and the Cowork mounts work again. KB5126052 (.NET) is still installed, so it is not the cause; it is KB5124008.

Caveats: this leaves the machine without the September security fixes until the update is reinstalled, and the Retail Demo content is only used by the store demo mode. It only applies if your CBS.log names the RetailDemo capability, so check first (copy the log to %TEMP% if it is locked):

Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern 'must be uninstalled first' | Select-Object -Last 5

confirmation, independent machine — same KB, same build.

ENVIRONMENT
Windows 11 Pro 25H2, build 26200.9445
KB5124008 installed 2026-09-08, first reboot 2026-09-09 01:30
Claude desktop app 1.49585.0 (Electron 44.2.0, Node 24.20.0)

SYMPTOM — identical
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
Plan9 share "c" is not mounted
ensure user: user <workspace-name> already exists unexpectedly: uid=1098

The shell starts; no connected folder is mounted. The named mount rotates
between attempts (outputs, uploads, .auto-memory) — all hang off share "c".
Resume fails and create fails, so it never self-heals.

ELIMINATED HERE (in addition to your bundle re-download)

• Tray-quit and relaunch of the desktop app
• A brand-new Cowork conversation
• A full Windows host reboot

TWO DATA POINTS THAT MAY NARROW IT

1. This is NOT the OneDrive-specific failure in #25293. Five folders are

connected — some OneDrive-synced, some plain local paths on C:. ALL of them
fail identically, so the trigger is not OneDrive sync.

1. WSL2 is unaffected on the same host, confirming your read. Docker Desktop

on the WSL2 backend ran throughout and its containers kept serving on
localhost the entire time the Plan9 shares were dead.

STILL WORKING, so the regression is isolated to the shell
device_list_dir / device_stage_files / device_commit_files (different
transport, full read+write), the cloud container's own bash, Chrome, and
locally-registered MCP servers reached via the desktop bridge.

IMPACT
A scheduled task whose write step ran through device_bash could not complete:
it gathered its data over the browser, failed at the write, dumped the result
to a text file and stopped. Recoverable by hand, but it fails silently from
the user's point of view until someone looks.

I have NOT uninstalled the KB — it is a security update and the workarounds
around the shell are cheap enough to live with. Reporting for signal.

Same here on Windows 11 Pro 25H2, Build 26200.9445, KB5124008 installed 09.09.2026, Claude Desktop 1.49585.0 (x64). Identical error text. Tested and ruled out: umlaut in the user path, OneDrive, full app restart, and a fresh test folder outside OneDrive without umlauts - all three shares fail. Uninstalling KB5124008 fixed it.

Same issue here, x64, Windows 11 Home. Adding data in case it helps.

Environment

• Windows 11 Home 25H2, build 26200.9445 (KB5124008 + KB5126052 installed 2026-09-09; KB5124007 on 2026-09-08)
• Claude Desktop 1.49585.0 (MSIX, per-user install, not provisioned)
• VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62, SDK 2.1.260
• Virtual Machine Platform + HypervisorPlatform enabled, hypervisorlaunchtype Auto, WSL not installed

Symptom

• device_bash fails on every call: sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared, connected folders "failed to mount"
• Persists after a full cold reboot (shutdown /r)
• File tools (list/stage/commit) keep working

Host side looks healthy (Microsoft-Windows-Hyper-V-Compute-Operational), identical to a working boot on 2026-09-04:

• VirtualMachine/Devices/Plan9/Shares Add c (C:\, port 9902, flags 16) → 0x00000000
• Add f (F:\, port 9905, flags 16) → 0x00000000
• No errors/warnings in that log since 2026-09-08

Timeline (CEST)

• 2026-09-09 00:18–01:03: ~40 shell calls OK (app 1.46388.4, KB not yet applied)
• 03:25 app auto-updated to 1.49585.0; 03:29–03:41 three Windows Update reboots (KB5124008)
• from 12:19 onward: 10/10 shell calls fail with the message above
• On this machine the app update and the KB landed in the same window, so I cannot separate them myself; the A/B in #92958 suggests the KB.

Second, separate problem: CoworkVMService does not recover after a crash

• 2026-09-09 16:25:56: CoworkVMService terminated unexpectedly (event 7034, exit code 1067), ~41 s after a clean app quit
• The app then logs Skipping auto-reinstall (Windows VM service is not running; a computer restart restores it) and every start fails with VM service not running until the service is started manually or the PC is rebooted
• The service has no failure/recovery actions, and they cannot be set by an admin: sc.exe failure CoworkVMService ... → OpenService FAILED 5: Access is denied
• Suggestion: declare restart-on-failure recovery actions for the service in the package, and/or have the app try StartService before giving up.
• Local workaround: a scheduled task, run as SYSTEM and triggered by event 7034, that starts CoworkVMService again. Tested: a killed service came back in under 30 s.

Confirming this on x64 with an independent reproduction.

Environment

• Claude Desktop 1.49585.0 (same build as the original report), Electron 44.2.0, Node 24.20.0
• win32 x64
• Windows 11 25H2, OS Build 26200.9445 (KB5124008 installed)
• Cowork cloud session linked to the desktop device

Symptom is byte-identical to the original report. Any device_bash call fails immediately with:

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

followed by:

[Note: mnt/<folder> failed to mount and cannot be reached from this shell.
Those connected folders are still reachable via device_list_dir /
device_stage_files / device_commit_files, by their paths on this device.]

Timing matches. KB5124008 shipped 2026-09-08. The first failures on this machine were 2026-09-09, three identical ones in a single session, which was enough to establish it as host-side rather than transient. No change was made to Claude Desktop, the connected folders, or the workspace in that window.

Two things worth adding for triage:

1. Re-granting the connected folder does not repair it. Requesting folder access mid-session succeeds instantly and restores device_list_dir / device_stage_files / device_commit_files, while device_bash continues to fail with the same error. The grant and the mount are separate paths. This matters because the two failures can present together and look like one problem: a cloud session can also start with connectedFolders: [] (see #86647), and re-granting fixes that one while leaving the shell dead.

1. The file bridge is unaffected and stays fully functional. Reads and writes to connected folders work normally the entire time the sandbox is down. That is a useful signal that the Plan9/Hyper-V regression is confined to the VM's share mounting and does not touch the bridge transport.

Not remediated here. We chose not to uninstall KB5124008, since it is a security update, and worked around it instead by routing shell-dependent work to the cloud container and file-writing work to Claude Code. Flagging that because the only known repair in this thread leaves the machine unpatched, which is a hard trade for anyone who cannot defer security updates. A workaround on the Cowork side, or a clearer surfaced error than a mount failure inside the guest, would help.

One small ask on the error surface: the host logs mounted 0/9 Plan9 shares and reports hr=0x0 success, and the user-visible failure only appears when a shell call is attempted, which can be well into a session. Failing loudly at VM start would have saved several sessions here.

Corroborating report for #92984: KB5124008 breaks Cowork Plan9 shares (26200.9445)

Next of many independent environment hitting this, with full version data. Confirming the repro and adding a couple of data points that may narrow the cause.

Summary

After the September 2026 cumulative update KB5124008 (OS build 26200.9445), the Cowork sandbox starts but mounts zero host folder shares. Every device_bash call fails at the share pre-check:

sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
[Note: mnt/<Folder> failed to mount and cannot be reached from this shell.]
Host-side file access (the stage/commit path the app uses to read and write connected folders directly) keeps working, so this is isolated to the sandbox’s Plan9 share mount, exactly as the original report describes.

Environment

Claude Desktop: 1.49585.0 (Electron 44.2.0, Node 24.20.0, win32 x64)
Windows image version: 10.0.26200.9445
Installed updates (all dated 2026-09-08): KB5124008 (Security Update), KB5124007 (Security Update), KB5126052 (Update)
WSL: version 2.7.13.0, kernel 6.18.33.2-2, WSLg 1.0.73.2, MSRDC 1.2.7214, DXCore 10.0.26100.1
Matches the reported Claude Desktop 1.49585.0 in the original issue.
Timeline: the sandbox worked for months, then stopped mid-day on 2026-09-10, two days after KB5124008 installed.

Observed failure pattern

Two distinct states, both traceable to the same break:

After a full PC reboot: the VM boots, but mounted 0/N Plan9 shares, so the shell errors on the missing mount.
After an app-only quit/relaunch (no reboot): the VM will not relaunch at all in the same Windows session. Every call returns Workspace unavailable. The isolated Linux environment on this device failed to start. until the next full reboot.
Extra data point that may help

On this machine, after the update the Microsoft-Windows-Subsystem-Linux optional feature was found State: Disabled, while VirtualMachinePlatform stayed Enabled:

dism /online /get-featureinfo /featurename:Microsoft-Windows-Subsystem-Linux
State : Disabled
dism /online /get-featureinfo /featurename:VirtualMachinePlatform
State : Enabled
Re-enabling the WSL feature (dism /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all) plus reboot got the VM to boot, but did not restore any Plan9 shares. So the WSL feature state is a separate side effect and not the mount cause. The mount failure survives with the WSL feature back on, which is consistent with the root cause being the updated p9 components (p9rdr.sys, p9np.dll) rather than WSL configuration.

Tried and did NOT help (matches original report)

Multiple full PC reboots
Full quit + relaunch of the Claude Desktop app (repeatedly)
Removing and re-adding the connected folder (plain NTFS / OneDrive folder)
Reinstalling WSL (wsl --install), wsl --update, wsl --shutdown
Re-enabling the WSL optional feature (booted the VM, mount still 0 shares)
Confirming VirtualMachinePlatform = Enabled and virtualization on
Only fix found

wusa /uninstall /kb:5124008
reboot; sandbox mounts again
Rolling back a security update is a poor ask for managed/corporate machines, which is most of the affected install base. A Cowork-side fix for the token-based Plan9 mount (flags=0x10 hasToken=true) against the updated p9rdr.sys / p9np.dll would let users stay patched.

Ask

Please prioritize a Cowork-side mount fix. KB5124008 is a routine monthly security update, so the affected population grows every day it stays patched, and the current guidance forces users to choose between a working product and an installed security patch.

Ruled out (all tested, all still fail):

• Folder location — reproduced with three unrelated trees: C:\Users\<username>\OneDrive\Documents\#Employment\Chat Uploads, C:\Users\<username>\OneDrive\Desktop\Stuff, C:\Users\<username>\OneDrive\Pictures\Fig Tree
• OneDrive — also fails with a plain local folder (C:\temp\claude) created after the fact
• Session/project scope — fails in four separate threads, in and out of a project, with fresh grants each time
• Restarting the desktop app
• Re-requesting folder access mid-session (returns alreadyGranted, no-op, mount unchanged)
• Full Windows reboot
• Uninstall → reboot → reinstall of the desktop app (reinstall returns the same 1.49585.0 build)
• WSL — not installed on this machine, so it isn't a WSL 9p regression
• Defender Controlled Folder Access — EnableControlledFolderAccess = 0

Unaffected throughout: device_list_dir, device_stage_files and device_commit_files all work normally with read and write, including into folders granted after the failure began. Only the shell mount is broken, which points at the 9p share layer specifically rather than the permission or transport layers.

Not yet tested: I have not uninstalled KB5124008, so I can't independently confirm OP's fix.

Workaround in the meantime: stage files into the cloud workspace, build there, and commit results back. Output is identical; it costs a round trip at each end.

Same failure on Windows 11 Home, build 26200, since 2026-09-10.

Every bash/device call fails immediately:

failed to mount /mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Local/Packages/
Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/.../outputs
as outputs: source path ... is under Plan9 share "c" which is not mounted
create: RPC error -1: ensure user: user <session> already exists unexpectedly

Notes that may help narrow it down:

• The whole "c" share is unmounted, not one folder. The error names whichever mount it

reaches first (outputs, then uploads on a later attempt) — so this is not the
OneDrive-specific issue (#25293), it is the share never attaching at all.

• Restarting the desktop app does NOT clear it. The failure is on RESUMING the session's

sandbox, and the leftover user account ("already exists unexpectedly") suggests stale
state keyed to the session id.

• Adding a new working directory mid-session forces a remount and still fails identically.
• MSIX/Store packaged install (AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache).

Additional data point not yet in this thread: the suggested fix does not work for
everyone. Uninstalling KB5124008 fails with 0x800F0825 — the update has been committed
and its uninstall payload removed, so Settings > Uninstall updates cannot remove it. That
leaves affected users with no workaround at the OS level.

Impact: Cowork is unusable for any document-generation workflow. I had to install Node.js
natively on Windows and rebuild my toolchain to keep working.

Confirming on a second machine: x64, Windows 11 build 26200, KB5124008 installed 2026-09-09, Claude Desktop 1.49585.0 — same day the Cowork VM stopped seeing any connected folder. Error in the guest is sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared, same as #93221. Have not rolled the KB back (security update).

Adding full diagnostics from another affected machine — and an important point the thread doesn't yet cover: on some machines KB5124008 cannot be uninstalled at all, so "uninstall the KB" is not a universal workaround.

Environment

• Windows 11 Home 24H2, build 10.0.26200.9445 (KB5124008 installed 2026-09-10 02:54, with KB5126052 .NET; KB5124007 on 2026-09-08)
• Claude Desktop, Microsoft Store / MSIX install (AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\...)
• Cowork local sandbox worked daily until 2026-09-10.

Failure signature (every bash call, immediate)

resume: RPC error -1: failed to mount .../outputs as outputs: source path ... is under Plan9 share "c" which is not mounted
create: RPC error -1: ensure user: user <session> already exists unexpectedly: uid=1377 gid=1377

The whole c share never attaches (error names whichever mount it hits first: outputs, then uploads). Not the OneDrive issue (#25293): a plain local path fails identically.

What I tried (all failed identically)

1. Restart app, full quit from tray, new conversation.
2. Adding a working directory mid-session (forces remount).
3. Deleted vm_bundles, let Claude re-download the VM. Fresh VM provisioned (leftover-user uid changed 1377 → 1001, proving a clean image); still fails the Plan9 mount → fault is host-side, not VM state.
4. Uninstalling KB5124008 — impossible here:

• Settings > Uninstall updates → 0x800F0825
• wusa /uninstall /kb:5124008 (elevated) → 0x800f0825
• DISM /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26 (elevated) → 0x800f0825, "DISM failed. No operation was performed."
• Root cause, from CBS.log:

``
Failed verifying that the target package: Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9278.1.35 has a full set of required FODs/LPs [HRESULT = 0x800f0825 - CBS_E_CANNOT_REMOVE]
Failed to re-install superseded versions for package: ...~26100.9445.1.26 [CBS_E_CANNOT_REMOVE]
``
CBS can't reconstitute the previous LCU (9278) — its FOD/language-pack payload is no longer complete in the component store — so the newer LCU can't be removed.

• DISM /Online /Cleanup-Image /RestoreHealth → "completed successfully", but Remove-Package still fails the same way (RestoreHealth repairs current components, not the superseded 9278 payload).
• Only restore point available is 2026-09-10 12:41 — after the update was applied at 02:54. Unusable.

1. Edition is Home, but the OP and #43896 / #31988 are Pro, so edition isn't the variable.

Net result

No OS-level way out on this machine: the update can't be removed and there's no pre-update restore point (short of an in-place repair install). Until Cowork tolerates the updated Hyper-V Plan9 server (p9rdr.sys / p9np.dll 10.0.26100.94xx), the local sandbox is unusable for a growing share of Windows users as the September CU rolls out. Rebuilt my toolchain natively (Node.js 24 + Word) to keep working. Happy to share full host/guest logs.

Confirming this on a second machine — different Windows edition and channel, and with a timeline that narrows down which components are responsible.

Environment

• Windows 11 Enterprise 25H2, build 10.0.26200.9445 (KB5124008 installed)
• note: the ProductName registry value still reads "Windows 10 Enterprise" on this build — that's the long-standing registry quirk, it is 11 Enterprise
• Claude Desktop 1.49585.0.0 (MSIX Claude_1.49585.0.0_x64__pzs8sxrjxfjjc)
• CoworkVMService: Running / Automatic
• Hyper-V (all features) + VirtualMachinePlatform Enabled; HypervisorPlatform Disabled
• Shares in play: C:\ (local NTFS) plus two mapped SMB network drives — 3 shares total
• Also installed in the same window: KB5124007, KB5126052 (.NET Framework), KB5126104 (.NET 8.0.31), KB5126106 (.NET 10.0.12)
• Corporate-managed SOE (updates arrive by policy)

Timeline — pins the regression to the binary replacement

| Time (local) | Event |
| --- | --- |
| 2026-09-10 06:15 | Cowork session mounts all shares fine — guest log shows mounted /mnt/.virtiofs-root/shared/h/... and .../shared/c/... for every path. Last known-good. |
| 2026-09-10 10:09 | KB5124008 replaces the Hyper-V/Plan9 binaries (file write timestamps below) |
| 2026-09-11 10:07 | First session after the update — host adds 3 shares, all hr=0x0, guest never mounts them; every shell call fails |
| 2026-09-11 11:15 | Full PC restart — no change |
| 2026-09-11 11:16 | Same failure, fresh boot |

So the last working session and the first broken one are under four hours apart on the same Claude Desktop build and the same VM bundle, with only the Windows binary replacement in between. Nothing on the Claude side changed.

Component versions after the update

vmcompute.exe        10.0.26100.8457   written 2026-09-10 10:09
vmwp.exe             10.0.26100.8457   written 2026-09-10 10:09
computestorage.dll   10.0.26100.9444   written 2026-09-10 10:09
p9np.dll             10.0.26100.9278   written 2026-09-10 10:09
p9rdr.sys            10.0.26100.9444   written 2026-09-10 10:09
vmbusr.sys           10.0.26100.8524   written 2026-09-10 10:09

Possibly useful for narrowing the cause: computestorage.dll (9444), p9rdr.sys (9444) and p9np.dll (9278) match the original report exactly, but vmcompute.exe and vmwp.exe here are 10.0.26100.8457, not 8875 as in the original report. Two machines with different vmcompute/vmwp versions, identical Plan9 component versions, identical failure — which points at the p9 components (p9rdr.sys / p9np.dll / computestorage.dll) rather than the VM worker process.

Host side looks completely healthy

[VM] User token set for Plan9 identity
[VM] Plan9 share added: c -> C:\ (port=9902, readOnly=false)
[Server] Adding network-drive share O (unc len=28)
[VM] Plan9 share added: o -> <network> (port=9914, readOnly=false)
[Server] Adding network-drive share H (unc len=37)
[VM] Plan9 share added: h -> <network> (port=9907, readOnly=false)
[VM] Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
[HCS] Calling HcsModifyComputeSystem (config len=152)
[HCS] HcsModifyComputeSystem returned: hr=0x0, lastErr=The operation completed successfully.
   ... identical for o (9914) and h (9907), all hr=0x0 ...
[VM] Sent plan9Shares notification (3 shares)

App log likewise reports success on every boot, before and after the update:

[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed (74ms)

Both local NTFS (C:) and mapped SMB shares fail identically, so this isn't cloud-files or network-drive specific.

How it surfaces to the user

Rather than the "no Plan9 drive shares mounted" message in the original report, the shell call fails on session resume and names the specific unmounted share:

bash failed on resume, create, and re-resume.
resume: 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/<guid>/outputs as outputs:
  source path ... is under Plan9 share "c" which is not mounted;
create: RPC error -1: ensure user: user <session-name> already exists unexpectedly:
  uid=1027 gid=1027

Worth noting the second half: once resume fails, the create fallback fails separately on a leftover guest user (already exists unexpectedly: uid=1027 gid=1027), so there is no recovery path — the session is wedged permanently and even a new conversation in the same workspace can't get a shell. A cleanup of the stale guest user would at least make the failure recoverable once the mount issue is fixed.

Confirming the reporter's "observation 1"

I can confirm the guest log (coworkd\user-<SID>.log) stops being written after the first boot of the day — mine ends at 07:20 today and contains nothing from the 10:07 or 11:16 sessions, so the mounted 0/N Plan9 shares line isn't capturable on a machine that's already been running. Anyone trying to collect that line will need to check the log immediately after the day's first VM boot.

On the workaround

wusa /uninstall /kb:5124008 isn't available to users on a managed SOE — the update is deployed by policy and would reinstall at the next cycle, and rolling back a security update isn't an end-user decision in the first place. For enterprise deployments a Cowork-side fix is the only viable path.

In the meantime, the file-read/write tools and the hosted connectors still work, so document and data work is unaffected; anything needing the shell (Python, file conversions, spreadsheet manipulation) is completely blocked.

Happy to capture anything further — I can grab the guest log on the first boot of a day if that would help.

First Windows 10 report in this thread, plus protocol-level detail that may narrow the attach failure.

Every report here so far is Windows 11 (26100 / 26200 / 28000). This machine is Windows 10 22H2 on the 19041 branch, and it fails identically.

Environment

• Windows 10 22H2, x64, build 19045.7725 — KB5122878 (September 2026 ESU cumulative) installed 2026-09-10
• Claude Desktop 1.52386.0, Electron 44.2.0, Node 24.20.0
• Four Plan9 shares (c, d, e, g) — all local fixed NTFS volumes, no network drives, no cloud-synced folders. One connected folder, on D:.
• Cowork mounted this same folder normally before the 2026-09-10 update batch. Every boot since fails.

Updates installed 9/9–9/10: KB5122878 (cumulative), KB5126146 (.NET), KB5127070 (WinRE), KB5126256 (ESU licensing), PowerShell 7.6.6. Of those, KB5122878 is the only package that services the Plan9 / HCS path.

Plan9 component versions

p9rdr.sys   10.0.19041.7663   LastWriteTime 2026-09-10 02:04:21
p9np.dll    10.0.19041.6157

Different servicing branch from the Windows 11 reports, but the same shape: p9rdr.sys recently serviced, p9np.dll lagging well behind it. Compare 9444 / 9278 on 26100.

Sequence on this machine, all the same day:

• 2026-09-10 — KB5122878 installed
• 2026-09-10 02:04:21 — p9rdr.sys rewritten
• 2026-09-10 22:50:13 — first failing boot in the guest log

Guest log — the 9p exchange

C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log, failing boot 2026-09-10 22:50:13:

[hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
[hyperv] 9p probe "c": Tversion msize=1048576 -> Rversion msize=262144 version="9P2000.L", type=101 tag=0xffff size=21
[hyperv] 9p probe "c": Tattach aname="c" -> Rlerror ecode=22 (invalid argument), type=7 tag=0x0 size=11
[hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
[hyperv] mounting Plan9 share "d" via vsock port 9903 at /mnt/.virtiofs-root/shared/d
[hyperv] failed to mount Plan9 share "d": Plan9 mount failed: invalid argument
[hyperv] mounting Plan9 share "e" via vsock port 9904 at /mnt/.virtiofs-root/shared/e
[hyperv] failed to mount Plan9 share "e": Plan9 mount failed: invalid argument
[hyperv] mounting Plan9 share "g" via vsock port 9906 at /mnt/.virtiofs-root/shared/g
[hyperv] failed to mount Plan9 share "g": Plan9 mount failed: invalid argument
[hyperv] mounted 0/4 Plan9 shares

What this adds: Tversion succeeds. The server responds, agrees on 9P2000.L, and downgrades msize 1048576 -> 262144. Tattach is what fails, with Rlerror ecode=22 (EINVAL).

So vsock transport, connection and version negotiation are all healthy. The regression is specifically in the attach step — which is where the token-based share identity (flags=0x10 hasToken=true in the host logs above) is presented. That seems consistent with the theory in this thread, and rules out a transport-level or negotiation-level cause.

Possibly worth checking whether the client's attach still sizes against the requested msize rather than the negotiated 262144, since that mismatch would also surface as EINVAL at exactly this step. Offered as a hypothesis, not a finding.

Rest of the VM is healthy

Same boot, immediately after the mount failures:

[coworkd] update-ca-certificates --fresh: 5.227s
[coworkd] installed 98 host CA certificates
[coworkd] checking reachability https://api.anthropic.com/ (timeout=30s)
[coworkd] reachability check passed (status=404)
[coworkd] connected, waiting for commands

Also present, matching reports above: user rcw-... already exists: uid=1005 gid=1005 and user recovery complete: recovered=13 skipped=1 failed=0.

Host-side bridge is unaffected, as others have found — device_list_dir, device_stage_files and device_commit_files all work against the same folder. Only the guest mount is missing.

Not verified

I have not rolled back, so there is no A/B on this machine. The file timestamp ties KB5122878 to p9rdr.sys, but it does not prove causation the way the rollbacks above do. KB5122878 is an ESU cumulative shipping as a combined SSU+LCU package, so wusa /uninstall is not available the way it was for KB5124008, and I would rather stay patched than DISM /Remove-Package a September security rollup on this machine.

I have the full log set and can pull anything else useful.

Second confirmed case, exact build match.

Windows 11 Pro, 25H2, build 26200.9445 — the same build named in this issue.
Claude Desktop 1.49585.0 (same build as the reporter in #93221).
Electron 44.2.0, Node 24.20.0, x64.
KB5124008: installed — not removed.

Every device_bash call fails immediately with exactly the string from this
issue:

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

followed by:

[Note: mnt/<FolderA>, mnt/<FolderB> failed to mount and cannot be reached
from this shell. Those connected folders are still reachable via
device_list_dir / device_stage_files / device_commit_files, by their
paths on this device.]

What I can confirm from a full day of use:

• 100% reproducible. Identical output on every call, hours apart.
• Restarting the Claude desktop app does not help. Closing it completely

(including the tray icon) and reopening does not help either.

• Both connected folders fail. Adding a second folder mid-session did not

change anything — the new folder appeared in the connected list and in
the failure note at the same time.

• The rest of the bridge is fully functional and was used all day:

get_device_info, device_list_dir, device_stage_files and
device_commit_files all work. Staging an 80 MB file and committing edited
files back to disk both succeeded. So this is specifically the shell
mount, not the connection.

Second affected machine, with one difference worth noting: on this system the KB
cannot be uninstalled, so the workaround from the original report is not available.

Environment

• Windows 11, OS build 26200, UBR 9445
• Claude Desktop (Cowork), MSIX package Claude_pzs8sxrjxfjjc
• Two configured shares, both under an OneDrive-synced path (C:\OD\...)

Symptoms — identical to the original report
Guest log (C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log):

[coworkd] Plan9 mount lost, remounting under /mnt/.virtiofs-root/shared
[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] mounted 0/2 Plan9 shares

Followed by, for each configured subpath:

optional mount Scheduled (...) failed, continuing: source path ... is under
Plan9 share "c" which is not mounted

The remount is retried on every session spawn and fails every time. Share "c" fails
as a whole, before any subpath is evaluated.

Why the workaround does not apply here

• Get-HotFix -Id KB5124008 -> GetHotFixNoEntriesFound
• DISM /Online /Get-Packages | Select-String "5124008" -> no match
• Settings > Windows Update > Update history > Uninstall updates -> KB5124008 is

not listed (5 entries shown, none of them this KB)

The UBR is nevertheless 9445, i.e. the build level associated with this KB, and the
failure started on the day it was installed. So the update appears to be present but
not removable on this machine. Uninstalling a different KB installed the same day was
considered but not attempted, since there is no evidence linking it to the failure.

Things tried, no effect

• Multiple reboots
• Reconnecting the folders in the app
• Full reinstall of Claude Desktop
• Re-downloading the VM bundle (~8 GB)

Possibly related
Both shares point at OneDrive-synced paths, and #25293 reports virtiofs/Plan9 mount
failures specifically against the OneDrive filesystem driver. Here the failure occurs
at the share level rather than the subpath level, so it may be unrelated — flagging it
in case the combination is relevant.

Happy to provide full host and guest logs, event log extracts or file-version tables
on request.

Confirming this from a second machine — different Windows edition and different hardware, same failure and same fingerprint.

Environment

| | |
|---|---|
| OS | Windows 11 Enterprise 25H2, build 26200.9445 |
| Updates installed 2026-09-09 20:59 (after required reboot) | KB5124008, KB5124007, KB5126052 |
| Claude Desktop | 1.49585.0.0, MSIX package Claude_pzs8sxrjxfjjc |
| Cowork VM SDK | 2.1.260 |
| WSL | 2.7.13.0, kernel 6.18.33.2-2 (updated during triage, see below) |
| User rights | standard user, no local admin (Entra-joined, Defender ATP) |
| Working folders | OneDrive/SharePoint-synced, cloud placeholders (reparse tag 0x9000701a) |

The original report lists Windows 11 Pro 24H2. This machine is Enterprise 25H2, so the fault is not edition-specific.

Errors, verbatim

bash failed on resume, create, and re-resume.
resume: 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/<session>/<sub>/local_<uuid>/outputs
  as outputs: source path ... is under Plan9 share "c" which is not mounted;
create: RPC error -1: ensure user: user exciting-amazing-mendel already exists unexpectedly:
  uid=1254 gid=1254

Also observed on the .auto-memory mount for spaces/<uuid>/memory.

Three observations that may help triage

1. ensure user … already exists unexpectedly is a retry artifact, not stale state

The session username is randomly generated per attempt. Four distinct names were observed across attempts: practical-ecstatic-edison (uid 1003), exciting-amazing-mendel (uid 1254), eloquent-amazing-cerf (uid 1010), pensive-zen-cray. A freshly generated random name cannot pre-exist.

Sequence appears to be: create provisions the user → the mount then fails → the retry re-runs create → it collides with the user its own previous attempt just created → abort.

After a full VM bundle rebuild the uid counter restarted near 1000 and climbed again with each failed attempt, which confirms the users are created fresh each time.

Making ensure user idempotent would not fix the mount, but it would stop the retry path from emitting a misleading second error and would allow a clean retry once the mount issue is fixed.

2. The failing mount sources are the app's own directories

The paths that fail are local-agent-mode-sessions/<…>/{uploads,outputs} and spaces/<uuid>/memory, both under AppData\Local\Packages\Claude_pzs8sxrjxfjjc\…. These directories exist on disk and are created fresh for each attempt (verified by timestamp).

So this is not about user folders, OneDrive, reparse points or permissions — share "c" is simply absent in the guest. Worth stating explicitly, because OneDrive is a tempting red herring here (see #25293, which is a separate, pre-existing issue).

Related: the mount source path is 240 characters, i.e. under MAX_PATH. Long-path theories do not apply.

3. Updating WSL changes the error signature but does not fix it

Updating WSL 2.6.3.0 → 2.7.13 (kernel 6.6.87.2-1 → 6.18.33.2-2) via the Microsoft Store changed the failure from

… is under Plan9 share "c" which is not mounted

to

Failed to start Claude's workspace
RPC error -1: SDK version 2.1.260 not verified at
  /mnt/.virtiofs-root/shared/c/Users/<user>/…/claude-code-vm/2.1.260/.verified

After the WSL update the two signatures alternate between attempts. The share path now appears to be traversed, but reading .verified through it fails. This may be a useful distinction between "share never registered" and "share registered but unusable".

Note for enterprise users: the WSL update went through the Microsoft Store without admin rights, unlike wsl --update, which requires elevation.

Ruled out on this machine

All of the following were performed and did not help:

1. Restarting the app including all background processes
2. Two full Windows restarts
3. VM session disk reset (sessiondata.vhdx renamed aside, recreated by the app)
4. Full VM bundle rebuild — claudevm.bundle renamed aside; the app re-downloaded rootfs.vhdx.zst (1.2 GB, expanded to 7.9 GB) plus fresh kernel, initrd and session disk
5. claude_desktop_config.json cleaned of unresolvable and malformed paths (one grant contained a literal backslash inside a folder name, from a SharePoint folder with /)
6. WSL updated to 2.7.13 (see above)
7. No application update available; 1.49585.0.0 is current on this machine
8. Hyper-V services running (vmcompute, vmms); no events in Hyper-V-Worker, VMMS or Compute admin logs during the failures
9. P9RdrService considered and dismissed — the p9rdr kernel driver is loaded, and P9Rdr is the Windows-side Plan9 client, not the server serving drive C: to the guest

Host-side evidence for KB5124008

C:\Windows\System32\drivers\p9rdr.sys
  version 10.0.26100.9444   modified 2026-09-09 09:27

The Plan9 driver was replaced at the exact time the update was staged.

What still works

• Read, Glob, Grep, Write, Edit on connected folders — these run host-side
• Web search, browser tools, MCP connectors (Microsoft 365, Google Drive, Fireflies)
• mcp__cowork__request_cowork_directory correctly grants folder permission
• mcp__cowork__allow_cowork_file_delete fails with "Could not find mount for path" on paths that Write accepts — consistent with a single root cause, since that call needs the guest mount table while the file tools do not

Secondary bug: "Enable Cowork VM Debug Logging" has no effect

Enabling Help → Troubleshooting → Enable Cowork VM Debug Logging and restarting the app writes no flag to claude_desktop_config.json and produces no output. logs\cowork_vm_node.log remained untouched (last write 2026-08-21) across several restarts.

By contrast, Enable Cowork SDK Debugging works immediately and sets "isCoworkSdkDebuggingEnabled": true, producing outputs\sdk-debug.txt per session.

This blocks users from supplying exactly the host-side VM logs that would help diagnose this class of failure.

Impact

No shell means no Python in the sandbox, which removes xlsx, pptx, docx and pdf handling from Cowork entirely. For finance and procurement work these are the primary deliverables. Claude Code is unaffected and is the current workaround.

Removing KB5124008 is not an option on a managed endpoint without admin rights, and it would mean giving up the September security baseline.

Switching install flavour is also not an option: Cowork requires the MSIX package on Windows, and the legacy .exe path yields Claude Desktop without Cowork.

Same error, same bundle hash 2a762adf…, Windows 11 Pro build 26100 (24H2), KB5124007 / KB5124008 / KB5126052 installed 9 Sep.

One difference from the reports above: on this machine the KB alone did not break it. A cold VM start at 2026-09-09 04:13, post-KB and post-reboot, succeeded (Startup complete, total time: 4949ms) on app 1.49585.0.0. Every start has failed since the app updated to 1.52386.0.0 on 10 Sep 18:10 — three cold boots across two reboots. Same Windows build, same VM bundle either side; the app update also replaces smol-bin.vhdx.

That suggests the guest agent version determines whether the patched Plan9 server rejects the mount.

This is really burning our colleagues on Windows. Workflows that we're heavily involved with have basically halted for them, and we don't have the option to revert due to security.

<html>
<body>
<!--StartFragment--><p dir="ltr">Adding a data point about the <strong>cost of the rollback workaround</strong>, because on this
machine <code>wusa</code>/DISM removal of KB5124008 did not stop at one update — and the
resulting six-month OS regression put the machine into a bugcheck loop. Also a
workaround that keeps you patched, at the bottom.</p>

<h2 dir="ltr">Environment</h2>

<ul dir="ltr">
<li>Windows 11 Home 25H2, build <strong>26200.9445</strong>, x64
(<em><code>CurrentVersion\ProductName</code> reads "Windows 10 Home" — the long-standing
registry quirk others have noted in this thread; it is 11 Home</em>)</li>
<li>ASUS ROG Strix G16, Intel Core Ultra 9 275HX, RTX 5070 Laptop + Intel iGPU</li>
<li>Claude Desktop / Cowork, Hyper-V sandbox, <code>CoworkVMService</code> running</li>
</ul>

<p dir="ltr">Same failure as everyone else. The app surfaces it as:</p>

<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">bash failed on resume, create, and re-resume.
resume: RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/&lt;user&gt;/
AppData/.../memory as .auto-memory: source path ... is under Plan9 share "c"
which is not mounted;
create: RPC error -1: ensure user: user &lt;session&gt; already exists unexpectedly:
uid=1367 gid=1367
A Windows update released September 8 prevents Claude's workspace from reaching
your files. We're tracking this issue. Claude Code is unaffected.</code></pre></div></div>

<p dir="ltr">Plan9 component versions here, all written 2026-09-08 23:25 — matching the
reports above exactly:</p>

<div dir="ltr">
File | Version
-- | --
p9rdr.sys | 10.0.26100.9444
p9np.dll | 10.0.26100.9278
computestorage.dll | 10.0.26100.9444
vmcompute.exe | 10.0.26100.1

</div>

<p dir="ltr" style="">A note on that last row: <code>vmcompute.exe</code> reports <code>10.0.26100.1</code> in its version
resource here, against 8875 and 8457 reported by others — but its
<code>LastWriteTime</code> is the same second as <code>computestorage.dll</code>, so the file <em>was</em>
replaced and the resource simply is not stamped per-LCU. Offered as a <strong>third</strong>
distinct <code>vmcompute.exe</code> value across machines with identical symptoms, which I
think strengthens @pyjamasam's and @preikschat's conclusion that the p9
components rather than the VM worker are the regression.</p>

<h2 dir="ltr" style="">The removal took two LCUs, not one</h2>

<p dir="ltr" style=""><code>dism /Online /Get-Packages</code> <strong>before</strong> removal listed four rollups:</p>

<div role="group" aria-label="Code" tabindex="0" style=""><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10
Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.8037.1.19
Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9168.1.19
Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26</code></pre></div></div>

<p dir="ltr" style="">Removed <strong>only</strong> <code>...9445.1.26</code>:</p>

<div role="group" aria-label="Code" tabindex="0" style=""><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">dism /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26 /NoRestart /Quiet
-&gt; exit 3010 (success, reboot required)</code></pre></div></div>

<p dir="ltr" style="">After the reboot the same command listed only <strong>two</strong>:</p>

<div role="group" aria-label="Code" tabindex="0" style=""><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.1742.1.10
Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.8037.1.19</code></pre></div></div>

<p dir="ltr" style=""><strong><code>UBR went 9445 -&gt; 8037</code>, not <code>9445 -&gt; 9168</code>.</strong> The August rollup
(<code>26100.9168.1.19</code>) was listed before the operation and absent after it. I did
not capture per-package <code>PackageState</code>, so I can only report the change in the
listing, not the mechanism. Others in this thread landed on 9278 and 9168, so
this is not the usual outcome — but it is worth knowing it can happen.</p>

<h2 dir="ltr" style="">What a six-month-old <code>dxgkrnl</code> did</h2>

<p dir="ltr" style="">Going back to 8037 regressed the kernel graphics stack:</p>

<div role="group" aria-label="Code" tabindex="0" style=""><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">dxgkrnl.sys 10.0.26100.7920 modified 2026-03-06</code></pre></div></div>

<p dir="ltr" style="">The NVIDIA driver in the DriverStore stayed where it was — <code>oem425.inf</code> /
<code>nvamsi.inf</code>, version <strong>32.0.16.1692 dated 2026-09-04</strong> — while the OS side went
back to March. On the first boot after removal:</p>

<ul dir="ltr" style="content-visibility: visible; contain: layout style paint;">
<li><strong>7 x Kernel-Power 41</strong> between 22:12 and 22:29 — a crash loop, recovered from
a phone</li>
<li>Two kernel minidumps, both <code>0x113 VIDEO_DXGKRNL_FATAL_ERROR</code>, parameters
<code>0x19, 0x2, 0x10DE, 0x2D58</code> (<code>0x2D58</code> is this GPU's PCI device ID)</li>
<li><strong>No Event ID 1001 was written</strong> for either crash — the parameters came from
reading the <code>PAGEDU64</code> dump headers directly</li>
<li><code>Win32_VideoController</code> then enumerated the Intel iGPU only; <code>nvlddmkm.sys</code> was
absent from <code>System32\drivers</code> and the RTX 5070 sat at <code>CM_PROB_PHANTOM</code></li>
</ul>

<p dir="ltr" style="content-visibility: visible; contain: layout style paint;"><strong>Important caveat, so this isn't over-read:</strong> this machine has a <em>pre-existing,
open</em> GPU fault. My own records show four earlier <code>0x113</code> between 2026-07-25 and
2026-08-05 with the same <code>0x19</code> subtype on the same adapter. (Three of the four
parameters identify the adapter and the subtype and could not have varied, so
"identical parameters" means same fault class, not a fingerprint.) <strong>The rollback
therefore did not create a new defect — it appears to have provoked a
known-fragile one</strong>, and I have no A/B that isolates causation. What I can state
is the association: no recorded GPU event since 2026-08-10, then two <code>0x113</code>
within ten minutes of first booting the reverted OS, and none since restoring
the update.</p>

<p dir="ltr">Also worth flagging for anyone following the rollback advice: a <strong>System Restore
point created minutes before the removal did not survive it.</strong> <code>CreateRestorePoint</code>
returned <code>0</code>, and afterwards the <code>root/default</code> <code>SystemRestore</code> CIM class returned
nothing and only hourly <code>DataVolumeRollback</code> shadow copies remained. The intended
escape hatch was gone at the moment it was needed.</p>

<h2 dir="ltr">Reinstalling fixed everything</h2>

<p dir="ltr">Lifted the update pause, let Windows Update reinstall KB5124008, rebooted:</p>

<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">UBR -&gt; 9445
Get-PnpDevice -Class Display:
Intel(R) Graphics OK CM_PROB_NONE
NVIDIA GeForce RTX 5070 Laptop GPU OK CM_PROB_NONE</code></pre></div></div>

<p dir="ltr">The dGPU re-bound on its own — the device node was phantom, not removed, and the
driver was intact in the DriverStore. No DDU, no driver reinstall.</p>

<h2 dir="ltr">A workaround that keeps you patched</h2>

<p dir="ltr">Since this regression is specific to Cowork's Hyper-V Plan9 path and <strong>WSL2 is
unaffected</strong> (confirmed by several people in this thread), the Linux toolchain
does not have to come from the Cowork sandbox at all:</p>

<div role="group" aria-label="powershell code" tabindex="0"><div><div></div></div><div>powershell</div><div><pre style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code class="language-powershell" style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre;"><span><span>wsl --install -d Ubuntu-<span style="color: rgb(94, 237, 237);">24.04</span>
</span><span>wsl -d Ubuntu-<span style="color: rgb(94, 237, 237);">24.04</span> -e bash -lc <span style="color: rgb(155, 233, 99);">'sudo apt update &amp;&amp; sudo apt install -y tesseract-ocr poppler-utils imagemagick python3 python3-pip'</span>
</span><span>wsl -d Ubuntu-<span style="color: rgb(94, 237, 237);">24.04</span> -e bash -lc <span style="color: rgb(155, 233, 99);">'cd /mnt/c/Users/&lt;user&gt;/&lt;your-folder&gt; &amp;&amp; &lt;command&gt;'</span></span></span></code></pre></div></div>

<p dir="ltr">Same files, same paths, fully patched machine, no Windows changes — WSL2 was
installed <em>after</em> KB5124008 here and mounts <code>/mnt/c</code> fine (WSL 2.7.12.0, kernel
6.18.33.2 on 10.0.26200.9445). Claude's file tools still read and write the
connected folder, so only <em>execution</em> needs relocating. It is a manual step per
command rather than an integrated shell, but it keeps the security update in
place.</p><!--EndFragment-->
</body>
</html>

Another x64 confirmation, including the rollback A/B.

• Windows 11 x64, build 26200.9445 with KB5124008 installed: every device_bash call fails with sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared, while the host logs add_plan9_shares completed on every boot.
• KB5124008 uninstalled + reboot: shares mount, the shell works immediately.
• Claude Desktop held constant at 1.49585.0 (MSIX), SDK 2.1.260, bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62. Windows build was the only variable.

Also ruled out here before the rollback, all without effect: new session, app restart, two full OS restarts, a plain local folder outside OneDrive, Defender Controlled Folder Access (off, no third-party AV), deleting rootfs.vhdx, a full re-download of claudevm.bundle + warm, reinstalling the SDK, and the MSIX "Repair" option in Windows Settings.

device_list_dir, device_stage_files and device_commit_files kept working throughout — only the shell was affected.

[!IMPORTANT] KB5124010 released on Sep 10th fixed the issue. If KB5124008 is already installed: installing KB5124010 on top of it does not fix the issue — Plan9 stays broken. The fix only seems to apply correctly when KB5124010 is installed fresh from baseline (i.e., without 5124008 in between). Confirmed on two separate machines. If you already have KB5124008 installed, here's the sequence that actually works: - Uninstall KB5124010 (if you already layered it on top of 4008) - Uninstall KB5124008 — this rolls back to baseline - Confirm Cowork's VM works again at baseline - Run Windows Update — it will offer KB5124010 directly (skipping 4008), and this time Plan9 is actually fixed

https://learn.microsoft.com/en-us/windows-insider/release-notes/release-preview-24h2-25h2/build-26100-9539-26200-9539

Independent x64 confirmation + completed rollback A/B (KB5124008 / 26200.9445)

Confirming this report on a second x64 machine, with a clean single-machine rollback A/B and two controls I have not seen posted elsewhere: a fresh-bundle test and a host/guest share-visibility pair. Recovery steps that actually work are at the end — wusa /uninstall does not.

Environment

• Windows 11 25H2 x64
• OS build: 26200.9445
• Update: KB5124008, installed September 9, 2026
• Claude Desktop: 1.49585.0.0
• Cowork VM bundle: 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 (version identifier, not per-instance)
• Guest SDK: 2.1.260

Claude Desktop remained at 1.49585.0.0 throughout all failed starts and the clean-bundle control described below.

Disclosure on the app variable

This machine also updated Claude Desktop from 1.34493.1.0 to 1.49585.0.0 on September 8 at 23:56, roughly a day before KB5124008 installed. I cannot separate the two from this machine's timeline alone, and I am not claiming to.

What I can add: the last logged success on this machine was 2026-08-21 on 1.34493.1.0 — add_plan9_shares completed (11ms) with no subsequent missing-share error — and every start since the September updates has failed identically. The app-constant rollback in this issue's original ARM64 report is what rules the app out; this report contributes the x64 reproduction and the host/guest visibility proof.

Repeated failure

Five pre-rebuild VM starts reproduced the same false-success sequence on September 10 at approximately 00:20, 13:16, 13:20, 13:25, and 13:30:

[VM:steps] vm_boot completed
[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed
[VM] Network status: CONNECTED
[VM:steps] sdk_install completed
[VM:start] Startup complete

Subsequent device_bash calls failed with:

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

There were 14 instances of that missing-share error before the bundle-control experiment. The connected-folder configuration was present: the host log recorded mounts=network:rw, so this was not an empty configured-mount list.

Host/guest proving pair

This file exists on the Windows host:

C:\Users\<user>\AppData\Roaming\Claude\claude-code-vm\2.1.260\.verified

A freshly booted guest nevertheless reported:

RPC error -1: SDK version 2.1.260 not verified at
/mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Roaming/Claude/
claude-code-vm/2.1.260/.verified

The host file exists, but the new guest cannot see it through the Plan9-backed path.

Fresh-bundle control

The original VM bundle was moved aside and Claude downloaded a completely fresh bundle. Rootfs, kernel, and initrd downloads/decompression completed and their checksums validated. The bundle hash is a pinned version identifier, so the re-downloaded bundle matching the original hash is the point: bundle content is provably not the variable.

The fresh bundle reproduced the boundary failure:

[VM:steps] vm_boot completed (169ms)
[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed (5ms)
[VM] Network status: CONNECTED
[VM:steps] sdk_install started
RPC error -1: SDK version 2.1.260 not verified at
/mnt/.virtiofs-root/shared/c/Users/<user>/.../.verified

A later shell attempt again produced:

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

This eliminates persisted guest state, VHD corruption, and old/new guest-image skew. The failure is at the Windows host-to-guest share boundary.

Other controls

• CoworkVMService is running and its named pipe exists.
• vmcompute and HvHost are running.
• The VM boots and reports network/API reachability.
• No third-party AV is registered; Defender Controlled Folder Access is off.
• File-bridge operations remain available; the VM-backed shell is the affected capability.

Rollback A/B — completed 2026-09-11

The controlled rollback deferred in the earlier part of this report has now been performed on this machine. Nothing else was changed between the two states.

| State | OS build | KB5124008 | Result |
|---|---|---|---|
| Before | 26200.9445 | installed | mounted 0/9 — every device_bash call fails with no Plan9 drive shares mounted |
| After | 26200.9168 | removed | Shell alive, $HOME/mnt/network mounted and readable, repo files listable |

Post-rollback verification, from the restored guest shell:

$ echo "shell alive"; ls $HOME/mnt/
shell alive
network
$ ls $HOME/mnt/network/docs/SESSION_PROTOCOL.md
/sessions/<id>/mnt/network/docs/SESSION_PROTOCOL.md

Claude Desktop was not changed for this test — it stayed at 1.49585.0.0 across both states. Combined with the app-constant evidence above, that closes the app-vs-KB ambiguity I flagged earlier on this machine: the app was constant, the KB was the only variable, and removing it restored the shares.

Uptime on the broken state was roughly 48 hours across many VM starts, so this is not a transient.

Recovery steps, for anyone else stuck here

wusa /uninstall /kb:5124008 does not work — KB5124008 ships as a combined SSU + LCU package and wusa refuses to remove the whole thing. DISM can remove the cumulative half.

There is also a naming trap worth flagging. On 25H2 the registry reports build 26200, but the servicing packages are versioned against the 26100 base, so filtering package names on the displayed build finds nothing:

# Pause Windows Update FIRST, or the KB silently reinstalls.

# Confirm the current revision (note: [Environment]::OSVersion always reports revision 0)
$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
"$($cv.CurrentBuild).$($cv.UBR)"      # -> 26200.9445

# Find the package - 26100, not 26200
$pkg = Get-WindowsPackage -Online |
  Where-Object { $_.PackageName -like "*RollupFix*26100.9445*" }
$pkg.PackageName
# -> Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26

Remove-WindowsPackage -Online -PackageName $pkg.PackageName -NoRestart
# reboot; expect a multi-restart "Reverting changes" cycle

After the reboot: 26200.9168, Get-HotFix -Id KB5124008 errors with "Cannot find hotfix," and Cowork mounts normally.

This is a workaround, not a resolution — it leaves the machine without a security update that closed actively exploited vulnerabilities, so it should be treated as temporary and reversed once a Cowork-side fix ships.

Offer

Happy to provide DISM package state, full cowork_vm_node.log captures from either state, or host-side share diagnostics on request. This machine can be moved between the two states again if a maintainer wants a specific measurement taken under controlled conditions.

Confirming on x64. Windows 11 Pro 26200.9445 (KB5124008), Claude Desktop / Cowork mode.

Every bash call into the workspace fails immediately:

failed to mount /mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Local/Packages/
Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/.../outputs
as outputs: source path ... is under Plan9 share "c" which is not mounted;
create: RPC error -1: ensure user: user <sandbox-user> already exists unexpectedly:
uid=1049 gid=1049

Notes that may help narrow it:

• A full reboot does NOT clear it. The failure is identical before and after.
• The share name in the error varies between "outputs" and "uploads" across

attempts, so it looks like whichever mount is tried first fails, not one
specific path.

• File-bridge tools are completely unaffected: read, write, glob and grep all

work normally against C:, a mapped network drive (J:), and a UNC path
(\\server\share). Only the isolated Linux workspace is dead.

• Net effect is no Python and no binary file reads (.xlsx/.dbf), so any task

needing execution has to move to the Claude Code CLI, which is unaffected.

Another confirmed x64 case, same signature, adding a data point.

Environment

• Windows 11 Pro 25H2, build 26200.9445 (KB5124008 installed 2026-09-10, reboot 01:33 local)
• Claude Desktop 1.49585.0 (MSIX Claude_pzs8sxrjxfjjc), Cowork SDK 2.1.260, VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62
• WSL not installed. VirtualMachinePlatform enabled. Windows Defender only.
• Last healthy VM boot 2026-08-23 (SDK 2.1.237, app 1.34493). No VM boots between then and the update. First boot after the update failed.

Guest log (C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log), first boot after the update:

[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] failed to mount Plan9 share "d": Plan9 mount failed: invalid argument
[hyperv] failed to mount Plan9 share "g": Plan9 mount failed: invalid argument
[hyperv] mounted 0/3 Plan9 shares

Every prior boot from July through 2026-08-22 logged mounted 2/3 Plan9 shares (the g share always failed with "file exists", unrelated).

Host service log (cowork-service.log) shows the same share config as the working August boots and reports success:

Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
HcsModifyComputeSystem returned: hr=0x0

App log (cowork_vm_node.log) then fails at SDK install because the guest cannot see the C: share:

[VM:start] Startup failed: Error: RPC error -1: SDK version 2.1.260 not verified at /mnt/.virtiofs-root/shared/c/.../claude-code-vm/2.1.260/.verified
[vm-stderr oneshot-] sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

The .verified file exists on the host and the SDK binary's sha256 matches .payload, so the payload is fine. The app's one-time auto-reinstall ran, could not replace the locked rootfs.vhdx, and did not help.

Replaced HCS binaries on this machine (all dated 9/8, installed 9/10): vmcompute.dll 10.0.26100.9444, computestorage.dll 10.0.26100.9444, p9rdr.sys 10.0.26100.9444, p9np.dll 10.0.26100.9278.

device_list_dir / device_stage_files / device_commit_files still work. I have not rolled back the KB.

Clean A/B with Claude Desktop 1.52386.0.0 — app and guest held constant

Most reports here are on 1.49585.0, and one comment above suggests the newer guest agent may be what determines whether the patched server rejects the mount. On this host it does not — 1.52386.0.0 fails on the patched build and works on the rolled-back one, with nothing else changed.

Held constant across both states: Claude Desktop 1.52386.0.0, the same coworkd / sdk-daemon binary (it self-updated before the last failing boot, so the same build is on both sides of the A/B), guest kernel 6.8.0-136-generic, and the same VM bundle.

• Package_for_RollupFix~…~~26100.9445.1.26 (KB5124008; displayed UBR 26200.9445, 25H2) → 0/2 shares mounted on every attempt; 5 consecutive mount attempts across 3 Windows reboots, device_bash unusable throughout.
• KB5124008 removed → Package_for_RollupFix~…~~26100.9168.1.19 → first VM boot after the reboot mounted both shares, and device_bash returned real output immediately (ls $HOME/mnt/ listed the connected folder; a 201-entry directory read back normally).

So on this machine the Windows cumulative was the only variable, on an app build newer than most reports in this thread. Adding it because I did not see this combination A/B'd here yet.

Confirmed here, too.

Same bug on Windows 10 from this week's Cumulative Update.

Data point: removing KB5124008 did not revert the Plan9 binaries on my machine, and the mount is still dead.

Windows 11, x64. Timeline:

• 2026-09-09 — KB5124008 installed, Cowork shares stop mounting (sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared).
• Before uninstalling, dism /online /get-packages showed Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26 | Installed, Release Type : Security Update, State : Installed, Completely offline capable : Undetermined (not flagged permanent).
• Ran wusa /uninstall /kb:5124008 /norestart + reboot. No error, machine booted fine.
• 2026-09-12 — Get-HotFix -Id KB5124008 → GetHotFixNoEntriesFound. Package is gone.

But the files did not go back:

(Get-Item C:\Windows\System32\drivers\p9rdr.sys).VersionInfo.FileVersion
10.0.26100.9444 (WinBuild.160101.0800)

(Get-Item C:\Windows\System32\p9np.dll).VersionInfo.FileVersion
10.0.26100.9278 (WinBuild.160101.0800)

Those are the same versions listed in this issue as the broken ones. device_bash still fails with the identical error; device_list_dir / device_stage_files / device_commit_files still work normally.

Possibly relevant: KB5124007 (09-08), KB5126052 (09-09) and KB5121003 (09-11) are still installed, so one of those may be holding the 9444/9278 binaries in place, or the rollback simply doesn't revert files a later cumulative also delivers.

Suggestion for anyone else considering the rollback: check the three file versions after rebooting before assuming it worked. Get-HotFix showing the KB gone is not evidence that the Plan9 components were reverted.

Help: Windows 11 update broke Claude Cowork, but KB5124008 cannot be uninstalled — is there still a way to recover?

I’m having a serious compatibility issue between Windows 11 25H2 and Claude Desktop/Cowork, and I’m hoping someone can help me figure out whether there is still a safe way to recover.

Here is what happened:

• On September 8, 2026, my PC was upgraded to Windows 11 25H2 (OS Build 26200.9445).
• After the upgrade, Claude Desktop’s Cowork could no longer access my local C: drive.
• I found that this appears to be related to KB5124008. Anthropic has an open GitHub issue describing the same problem: Cowork’s Plan 9 file-sharing/mounting fails after KB5124008, while uninstalling the update reportedly fixes it.
• I checked my system and confirmed that KB5124008 is installed.

However, I cannot uninstall it normally:

1. Running:

wusa /uninstall /kb:5124008

says that the update cannot be uninstalled because it is required as a Microsoft Windows security update.

1. I also tried Windows Recovery Environment → Uninstall Latest Quality Update, but Windows says that it cannot uninstall the latest quality update.

1. I then checked the installed packages with DISM and found:

Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26

DISM identifies it as:

Description: Fix for KB5124008
Status: Installed
Version: 10.0.26100.9445

1. I tried removing it offline with:

DISM /Image:C:\ /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26

but DISM returned:

“The package cannot be uninstalled because it is a permanent package.”
Error: 0x800F0825

So it appears that this particular package is marked as permanent and cannot be removed through DISM either.

The rollback problem

At this point, I considered rolling Windows back to the previous version.

Initially, C:\Windows.old did exist and appeared to contain the previous Windows installation. However, earlier today I used WPS’s C: drive cleanup tool because my C: drive was running out of space. I believe it removed the Windows rollback files.

Now:

• Windows Settings → Recovery → Go back says:

> “Sorry, but you can’t go back. The files needed to go back to the previous version of Windows have been removed from this PC.”

• DISM /Online /Get-OSUninstallWindow returns Error 1168: Element not found.

• C:\$Windows.~BT is no longer present.

• I also checked both C:\$RECYCLE.WPS and C:\$Recycle.Bin, but there is nothing useful there.

My current question

Is there any safe way to recover the Windows rollback files (especially Windows.old) and restore the ability to roll back to the previous Windows version?

Or, if that is no longer possible, is there another safe method to remove/revert KB5124008 without reinstalling Windows from scratch?

I really want to avoid manually deleting anything from WinSxS/CBS or making potentially dangerous registry changes.

Any advice would be greatly appreciated.