[BUG] Cowork Windows: September 2026 cumulative update breaks Plan9 share attach — device_bash dead on both ARM64 (KB5124012 / 28000.2954) and x64 (KB5124008 / 26200.9445); confirmed by rollback A/B on five machines

x64 confirmation — same failure on Windows 11 Pro 25H2 (26200.9445, KB5124008), fixed by uninstalling the update

Not ARM64-specific. Same night, same app/SDK/bundle, same guest-side error text. KB5124008 is the 2026-09 cumulative for the 26100/26200 (24H2/25H2) branch; KB5124012 in the OP is the same month's cumulative for the 28000 branch.

Environment

• Windows 11 Pro 25H2 x64, build 26200.9445 after the 2026-09 cumulative update KB5124008 (+ SSU KB5124007), installed by Windows Update during the night of 2026-09-08→09 with a forced reboot
• Claude Desktop 1.49585.0.0 (MSIX, Claude_1.49585.0.0_x64__pzs8sxrjxfjjc), SDK 2.1.260, VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62
• Hyper-V role enabled; Windows Sandbox was enabled

Symptom — differs from OP because the first consumer of the missing share here is the SDK install, not device_bash:

Failed to start Claude's workspace
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

Host side is intact: claude-code-vm/2.1.260/ contains claude (214,687,216 bytes), .payload and .verified; sha256(claude) matches the hash in .payload.

Guest side — C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log, every VM 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] mounted 0/1 Plan9 shares
[coworkd] Plan9 mount lost, remounting under /mnt/.virtiofs-root/shared
[hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
...
optional mount <folder> (...) failed, continuing: source path ... is under Plan9 share "c" which is not mounted

So on x64 the guest's mount of share c fails explicitly with EINVAL rather than silently attaching nothing; the net result is the same — 0/1 shares, nothing under /mnt/.virtiofs-root/shared/c is visible, and the .verified check is simply the first thing to trip over it. cowork-service.log shows the VM booting, sdk-daemon connecting and CA certificates installing normally on every attempt.

Ruled out (no effect): in-app "Reinstall workspace" (bundle re-downloaded and re-extracted, rootfs.vhdx/vmlinuz/initrd recreated), deleting and re-downloading claude-code-vm/2.1.260, firewall (no block rules), HNS restart, ACL changes on the SDK folder.

Fix: uninstall KB5124008 → build 26200.9168 → Cowork starts immediately with the same app, SDK and bundle. Note for others: Settings refuses to uninstall the LCU while the Windows Sandbox feature (Containers-DisposableClientVM) is enabled — disable it first (dism /online /disable-feature /featurename:Containers-DisposableClientVM), reboot, then uninstall. Updates paused until this is fixed.

Suggestion: surface the Plan9 mount failure in the UI. "SDK not verified" points at file integrity and cost me four hours in the wrong direction.

x64 data point: same silent add_plan9_shares failure on Windows 11 25H2 x64, triggered by KB5124008 (26200.9445)

Adding an x64 confirmation, since the issue notes x64 status is unknown.

Environment

• Windows 11 25H2, x64 (AMD64), build 26200.9445
• Claude Desktop 1.49585.0.0 (MSIX), VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 — unchanged across working and broken boots
• Updates installed Sep 9 (local time): KB5124007 (00:00), then KB5124008 + KB5126052 (00:45)

Symptom — identical to the ARM64 report. add_plan9_shares logs completed with no error, but every device_bash call fails before the shell runs:

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

device_list_dir / device_stage_files / device_commit_files on the same connected folders keep working — only the shell-side mount is gone.

Timeline (from the Setup event log and cowork_vm_node.log)

| Time (Sep 9) | Event |
|---|---|
| 00:00:52 | KB5124007 installed |
| 00:39:23 | last successful device_bash (mounts=Subtitle Editor v2:rw, no warning) |
| 00:45:18 | KB5124008 + KB5126052 installed |
| 00:46:45 | VM boot — add_plan9_shares completed (11ms) |
| 00:47:20 | first no Plan9 drive shares mounted — every call since fails |

The log has zero occurrences of that warning before 00:47:20 and 8 since. The last healthy run falls between KB5124007 and KB5124008, so KB5124008 (or KB5126052, installed in the same minute) is the candidate.

Ruled out

• Drive/path: folders on both C: and D: fail in the same call
• Ordering: full app restart with the folder already connected still yields no share
• Privileges: launching the app elevated changes nothing
• Windows 9p generally: WSL2 drvfs 9p mounts of C:, D:, E: all work fine
• App/bundle change: bundle hash identical before and after

Caveat: I have not done the rollback A/B on this machine, so this is a timeline bisect, not a confirmed cause.

Confirming on a second machine. Same symptom, same timeline, independent of the reporter.

Machine: ASUS Zenbook, Windows 11 ARM64, build [xxxxx.xxxx after the update; check winver]. Claude desktop app [version from About], not updated or reinstalled at any point during this.

Timeline (UK time):

Tue 8 Sept, through 16:27: device_bash working normally all day, dozens of calls, files written and read back.
Wed 9 Sept, early hours: KB5124012 installed by Windows Update. [Confirm from Settings > Windows Update > Update history.]
Wed 9 Sept, 07:14 onward: every device_bash call fails with sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared. Re-tested across two separate Cowork sessions in two different projects at 07:19 and 07:37, three connected folders in one and two in the other. All named as failed to mount. Not transient.

What matches the report exactly: the app reports the folders as connected, nothing errors at the host end, and the only signal is the guest shell finding nothing under the mount point. A session that never runs a shell command would not notice.

What still works, tested rather than assumed: directory listings by device path (names, sizes, mtimes), staging individual files into the container, and the write path (compose in container, commit by file id to a device path), confirmed on disk at the expected byte size at 07:21 and again at 07:45.

I have not rolled the KB back, so I cannot add to the A/B evidence, but the before/after boundary on this machine is the same update on the same night with the app held constant.

Happy to pull host-side logs if you say which file; the add_plan9_shares completed line with zero shares attached is the thing I would expect to find.

@Harskov Your KB5124008-vs-KB5126052 ambiguity is resolved on my machine: I uninstalled only KB5124008 (26200.9445 → 26200.9168); KB5126052 is still installed, and Cowork works. So KB5124008 alone is the trigger.

One more data point for the maintainers: on my machine the failure is not entirely silent on the guest side — C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log shows the guest's own mount attempt failing (mounting Plan9 share "c" via vsock port 9902 → Plan9 mount failed: invalid argument), before sandbox-helper reports no shares. That log may be worth checking on your side too.

Draft comment for https://github.com/anthropics/claude-code/issues/92958 Prepared 2026-09-09. Paste everything below the line into the "Add a comment" box. One spot needs your confirmation — marked [CONFIRM] — edit or delete it before posting.

---

Same failure on x64 — this is not ARM64-specific. The trigger looks like the September 2026 Patch Tuesday, which shipped as a different KB per servicing branch.

I'm hitting the identical no Plan9 drive shares mounted failure on Windows 11 25H2 x64, beginning the day the September update installed.

The KB number differs from the one in this issue because Microsoft published the 8 September 2026 cumulative update once per branch:

| KB | Branch | Build | |
|---|---|---|---|
| KB5124012 | 26H1 | 28000.2954 | ← this issue |
| KB5124008 | 24H2 / 25H2 | 26100.9445 / 26200.9445 | ← this report |
| KB5122880 | 23H2 | 22621.7582 | |

So the variable common to both reports is the September release itself, not the architecture.

Environment

• Windows 11 Home 25H2, OS build 26200.9445, x64 (12th Gen Intel Core i5-1235U)
• KB5124008 installed 2026-09-09; the failure began the same day
• Claude desktop app 1.49585.0.0 — the same build as the original report
• Prior build 26200.9168 (KB5121003, installed 2026-08-15) worked normally; device_bash was in daily use up to 2026-09-08

Symptom

Identical string to the original report:

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

Every device_bash call fails at startup, including a bare echo. The shell never starts, so there is no in-VM diagnostic to run.

Scope of the breakage

• device_bash — dead.
• device_list_dir / device_stage_files / device_commit_files — still working. Reads and writes to the connected folder succeed.

The folder connection itself is therefore intact; what fails is specifically the share attachment into the sandbox VM.

Possibly related, lower confidence: during the same session, device_commit_files returned success while subsequent device_stage_files read-backs served the previous version of the file for several minutes. Writes did land, but only after retries and content-level verification. May be an independent staging-cache issue; noting it in case it shares a cause with the share layer.

Ruled out

• Restarting the Claude desktop app — no effect.
• Full machine reboot — no effect.

Both consistent with an OS-update cause rather than stale app or VM state.

[CONFIRM] A second Windows desktop on this account shows the identical failure starting the same day.

Caveat: not A/B confirmed on this branch

I have not removed KB5124008, as it is a cumulative security update. So the x64 evidence here is correlational — same error string, same app build, same release wave, same day — rather than the clean rollback proof in the original report. If someone on 24H2/25H2 can spare the rollback, that would close the gap.

Ask

1. Worth widening the title and scope beyond ARM64 — anyone on 24H2/25H2 searching for KB5124008 or build 26200.9445 will not find this issue as it is currently titled.
2. Is there any mitigation short of removing a security update?

x64 data point — same failure on Windows 11 25H2 x64 after KB5124008, the sibling of KB5124012

This issue is scoped to ARM64. I'm seeing the same failure on x64, triggered by the KB released alongside KB5124012 in the same September 2026 Patch Tuesday.

Environment:

Windows 11 Pro, x64, OS build 26200 (25H2)
Claude Desktop 1.49585.0 — same version as this issue
Electron 44.2.0, Node 24.20.0
Hyper-V vmms: Running

Every device_bash call, including a bare echo hello, exits 1 before the command runs:

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

Timeline:

Worked normally through 2026-09-08
KB5124007 installed 2026-09-08
KB5124008 + KB5126052 installed 2026-09-09
Broken from 2026-09-09

KB5124008 is the September 2026 cumulative for 24H2/25H2 (builds 26100.9445 / 26200.9445). If KB5124012 is the confirmed trigger on ARM64, KB5124008 is its 24H2/25H2 counterpart.

Ruled out on this machine:

Windows Home / missing vmms (#27906) — Pro, vmms running
OneDrive placeholder files (#25293) — a plain C:\Users\<user>\ClaudeTest with no spaces or hyphens fails identically
Spaces/hyphens in path (#31988) — same clean folder fails
Transient state — persists across app restart and a full OS reboot
WSL — not installed, and irrelevant since Cowork uses Hyper-V

The error says "no Plan9 drive shares mounted", consistent with this issue's finding that add_plan9_shares reports success while attaching zero shares.

I haven't attempted a KB rollback (managed corporate machine), so I can't offer A/B confirmation. Possibly related: Microsoft Q&A reports File History breaking after KB5124008 + KB5126052, which may indicate a shared storage/filter-driver change in this cumulative.

device_list_dir, device_stage_files and device_commit_files all still work normally — the folder is readable and writable, only the in-place shell is gone.

Suggest widening this issue's scope beyond ARM64.

Confirmed on x64 — not ARM64-specific. Rollback A/B below.

Intel Core i7-12700, x64. Windows 11 25H2. Claude desktop app 1.49585.0, held constant across the whole test.

Broken state

Build 26200.9445, KB5124008 installed 2026-09-08
Every device_bash call, including a bare echo, fails before the command runs: sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
Onset the same day KB5124008 installed. The shell was demonstrably working earlier that afternoon — a gh call succeeded before 16:08 UTC — and was dead by the next session.

Did not help: full app restart with every process killed; wsl --shutdown; a complete reboot; re-granting the connected folder.

Not affected: the file tools (device_list_dir, device_stage_files, device_commit_files) continue to read and write the same connected folder normally. The folder grant and the host-side bridge are intact — only the share attach into the VM fails.

Fixed state (A/B)

Paused Windows Update, uninstalled KB5124008 via Settings → Update history → Uninstall updates, rebooted
Build 26200.9168 (KB5121003, 13 August)
device_bash starts immediately; the mount is present; gh works again

Only Windows varied. Same controlled shape as the KB5124012 rollback in the original report.

Scope: KB5124008 is the 24H2 / 25H2 sibling of KB5124012 from the same 8 September 2026 release (26100.9445 / 26200.9445 vs 28000.2954). The ARM64 in the title is the reporter's hardware, not the boundary of the defect — it shipped to multiple servicing branches under per-branch KB numbers. A second x64 machine on this account shows the identical failure.

**x64 too, with two things not yet in the thread: (1) on my machine the guest dies earlier than the Plan9 step — the session disk comes up read-only — and (2) KB5124008 cannot be uninstalled here, so the rollback workaround is not available to everyone.**

Environment: Windows 11 Pro 25H2 x64, build 26200.9445 (KB5124008 installed 2026-09-09, reboot 09:54 local / 05:54 UTC). Claude Desktop 1.49585.0.0 MSIX. VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62. Host: Plan9 share added: c -> C:\ (port=9902) every boot, add_plan9_shares completed (4–45ms). App-side symptom identical to the OP (... is under Plan9 share "c" which is not mounted on outputs / uploads / .auto-memory).

1. Guest-side A/B on the same app version, same day (C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log)

The app updated to 1.49585.0.0 at 05:16 UTC, before the KB reboot. That boot was healthy at the guest level:

2026/09/09 05:16:52 [coworkd] session disk mounted successfully at /sessions
2026/09/09 05:16:53 [hyperv] mounted 2/2 Plan9 shares

Every boot after the KB reboot (86 of 86 so far) stops here and never reaches mounting Plan9 share:

[coworkd] detected Hyper-V host, loading vsock/9p modules
[hyperv] modules loaded successfully
[coworkd] resolved host share base: /mnt/.virtiofs-root/shared
[hyperv] found session disk at /dev/sdc
[tapvsock] connected to host network, bridge running
[coworkd] formatting session disk /dev/sdc with ext4
[coworkd] could not mount session disk: failed to format session disk: exit status 1: mke2fs 1.46.5 (30-Dec-2021)
/dev/sdc: Read-only file system while setting up superblock

Counts for today: could not mount session disk = 86, mounting Plan9 share "c" = 1 (the pre-KB boot), Plan9 mount failed = 0. So on this machine the shares are never attempted; the guest gives up after the session disk. sessiondata.vhdx on the host has no read-only attribute and the NT VIRTUAL MACHINE\<id> SID has Full Control, so the RO flag is being applied at the virtual SCSI attach, not the file. @yuriyda's Plan9 mount failed: invalid argument and my Read-only file system on the block device look like two faces of the same thing: guest-side device attaches behaving differently after the September cumulative update. Two odd details that may help whoever debugs it:

• coworkd goes straight to formatting an existing 10 GB session disk (no "mount failed, formatting" line before it), which suggests the existing ext4 superblock was not recognised either.
• The daemon still answers RPC afterwards (the app logs Startup complete / API reachability: REACHABLE), so from the app's side the VM looks up; only device_bash fails.

Also seen during the day: one CoworkVMService crash (SCM 7034 "The Claude service terminated unexpectedly"), two VM connection timeout after 60 seconds with last completed step: add_plan9_shares, each followed by an auto-reinstall of the bundle, and two claude.exe MoAppHang events.

2. Uninstalling KB5124008 is not possible on this machine

• wusa /uninstall /kb:5124008 → 0x800f0825
• DISM /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26 → 0x800f0825 CBS_E_CANNOT_REMOVE. CBS.log: Capability: RetailDemo.OfflineContent.Content~~~~0.0.1.0 must be uninstalled first. The RTM version is missing.
• DISM /Remove-Capability for that capability → 1168 Element not found (not in FOD metadata); DISM /Remove-Package on its wrapper package → Only package owners can remove package (0x80070005).
• WinRE → Uninstall latest quality update → "Windows ran into a problem", system unchanged.
• No pre-update restore point survived.

So for at least some users the only fix will be a guest-side change from Anthropic. Happy to share full logs privately or run a build with extra logging around the session-disk attach / 9p mount.

<html>
<body>
<!--StartFragment--><h2 dir="ltr">Same failure on x64 / Windows 11 25H2 (build 26200.9445, KB5124008) — not ARM64-only</h2>

<p dir="ltr">Confirming this reproduces on the mainstream <strong>x64</strong> branch, with the sibling cumulative update released the same day. The issue title scopes this to ARM64 / 26H1, but the affected population is much larger.</p>

<h3 dir="ltr">Environment</h3>

<div dir="ltr">
Property | Value
-- | --
OS | Windows 11 25H2, build 26200.9445 (x64)
Processor architecture | AMD64 (native, no emulation)
Triggering update | KB5124008, installed 2026-09-08 — the 24H2/25H2 sibling of KB5124012, released the same day (2026-09-08)
Also installed 2026-09-08 | KB5124007, KB5126052 (.NET Framework)
Previous cumulative | KB5123304, installed 2026-08-12
Claude Desktop | 1.49585.0 (MSIX-packaged: Packages\Claude_pzs8sxrjxfjjc)
Electron / Node | 44.2.0 / 24.20.0
Machine | Lenovo laptop, AD-joined (managed)
Free space on C: | > 300 GB

</div>

<h3 dir="ltr">Error</h3>

<p dir="ltr">Identical in shape to the original report — same guest-side origin, same message:</p>

<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); 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;guid&gt;/&lt;guid&gt;/local_&lt;guid&gt;/outputs as outputs:
source path ... is under Plan9 share "c" which is not mounted</code></pre></div></div>

<h3 dir="ltr">Timeline</h3>

<ul dir="ltr">
<li><strong>2026-08-19</strong> — last <code>add_plan9_shares</code> entry in <code>cowork_vm_node.log</code>; local sessions working normally</li>
<li><strong>2026-09-08</strong> — KB5124008 installed</li>
<li><strong>2026-09-09</strong> — first local session after the update fails with the error above; every subsequent attempt fails identically</li>
</ul>

<h3 dir="ltr" style="">Host side is fully healthy — this is the notable part</h3>

<p dir="ltr" style="">Everything on the host reports success. There is no error anywhere to act on:</p>

<ul dir="ltr" style="">
<li><code>VirtualMachinePlatform</code> — <strong>Enabled</strong></li>
<li><code>HypervisorPlatform</code> — <strong>Enabled</strong></li>
<li><code>vmcompute</code> — <strong>Running</strong> (StartType Manual). Full Hyper-V role not installed; <code>vmms</code> absent, which is expected for this configuration.</li>
<li><strong><code>Microsoft-Windows-Hyper-V-Compute-Admin</code>, last 48 h: 5 events, all Event ID 1001, all Information — "The Host Compute Service started successfully."</strong> Zero errors, zero warnings, across 5 separate launch attempts on 2026-09-09 (01:49:13, 01:51:20, 10:51:08, 10:55:05, 11:02:27).</li>
<li><code>vm_bundles\claudevm.bundle\rootfs.vhdx</code> mtime is current, so the VM disk is attached and the guest boots — consistent with the error originating inside the guest.</li>
</ul>

<p dir="ltr" style="">This corroborates the central claim of this issue: the share attachment fails <strong>silently</strong>, with no HRESULT and no host-side event. HCS itself considers the launch successful.</p>

<h3 dir="ltr" style="">Additional finding: this is not limited to local-agent-mode</h3>

<p dir="ltr" style="">The same breakage also kills <code>device_bash</code> in <strong>cloud</strong> sessions linked to this machine. Connecting a folder to a cloud session succeeds, and <code>device_list_dir</code> / <code>device_stage_files</code> / <code>device_commit_files</code> all work normally — those go through the desktop app's host-side file API. But any shell command on the device fails immediately:</p>

<div role="group" aria-label="Code" tabindex="0" style=""><div><div></div></div><div><pre style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

[Note: mnt/Projects failed to mount and cannot be reached from this shell.]</code></pre></div></div>

<p dir="ltr" style="">That is the second line of the original report reproduced verbatim, on x64. Both features share the same local Linux VM, so the blast radius of this regression is larger than local-mode sessions: it removes local shell execution from cloud sessions too, on any affected machine.</p>

<p dir="ltr" style="">Useful as a low-friction reproducer — no local session needed, just a connected folder and one <code>device_bash</code> call.</p>

<h3 dir="ltr" style="">Ruled out</h3>

<ul dir="ltr" style="">
<li>Disk space (&gt; 300 GB free)</li>
<li>OneDrive / Cloud Files — <code>CldFlt</code> is loaded (3 instances) but the failing path is under packaged <code>AppData\Local</code>, not a synced folder</li>
<li>Stale session state — a brand-new local session fails identically</li>
<li>App version / reinstall — unchanged at 1.49585.0 across working and broken periods</li>
<li>Third-party security filter drivers — <code>fltmc filters</code> shows <strong>only <code>WdFilter</code></strong> (Defender). No third-party EDR/AV minifilter. Full stack: <code>bindflt</code>, <code>UCPD</code>, <code>LnvMSRIO</code>, <code>WdFilter</code>, <code>storqosflt</code>, <code>wcifs</code> (0 inst.), <code>CldFlt</code>, <code>bfs</code>, <code>FileCrypt</code> (0 inst.), <code>luafv</code>, <code>UnionFS</code> (0 inst.), <code>npsvctrig</code>, <code>Wof</code>, <code>FileInfo</code></li>
<li>Virtualization prerequisites and services — all enabled and running (above)</li>
<li>Full app quit (tray → Quit), End task, End process, and <strong>3 full Windows reboots</strong> — no effect</li>
</ul>

<h3 dir="ltr" style="">One correction to the original report</h3>

<p dir="ltr" style="">The <code>add_plan9_shares</code> duration heuristic (4–12 ms after breakage vs. 0–9 ms historically) does not hold up as a discriminator. In this machine's log, durations from <strong>known-working</strong> sessions range <strong>0–21 ms</strong>, including several 0 ms entries (2026-07-31, 2026-08-05, 2026-08-18) and 21 ms / 18 ms / 17 ms entries. Duration appears to be noise here, so it is probably not worth chasing as a signal.</p>

<h3 dir="ltr" style="">Open question — where does 1.49585.0 write VM logs?</h3>

<p dir="ltr" style=""><code>...\LocalCache\Roaming\Claude\logs\cowork_vm_node.log</code> has <strong>no entries after 2026-08-19</strong> (file mtime 2026-08-24), so today's five failed attempts left no trace in it. A recursive scan of <code>LocalCache</code> for files modified in the last 48 h returns Chromium/Electron state, <code>sentry\session.json</code>, <code>sentry\scope_v3.json</code>, <code>config.json</code> and <code>rootfs.vhdx</code> — but no log file.</p>

<p dir="ltr" style="">So I cannot supply the <code>add_plan9_shares started</code> / <code>completed</code> pair for a failing run, which would be the direct confirmation that it reports success with zero shares attached. <strong>If you can point me at the correct log location or a verbose/debug flag for this version, I will attach a full trace of a failing launch.</strong> (Sentry state was updated during the failures, so telemetry for these runs likely reached you already.)</p>

<h3 dir="ltr" style="">Not attempted: KB removal</h3>

<p dir="ltr" style="">The confirmed workaround from the original report is not viable here. KB5124008 is the September security cumulative for the mainstream branch, on an AD-joined managed machine, and it includes Secure Boot certificate deployment work. Removing it would drop the month's security fixes and be re-pushed by Windows Update. This is precisely why an app-side or Microsoft-side fix matters rather than a rollback workaround.</p>

<h3 dir="ltr" style="">Impact</h3>

<p dir="ltr" style="">Local-mode sessions are completely unusable. Cloud sessions still run, and file access to connected folders still works through the host-side API, but <code>device_bash</code> is dead on this machine — so any workflow that runs commands, scripts or tooling on the user's own files has to fall back to staging each file into the cloud container and committing the result back. Workable, but materially slower and more token-expensive for exactly the tasks the local VM exists to make cheap.</p>

<h3 dir="ltr" style="">Request</h3>

<p dir="ltr" style="">Please consider widening the scope of this issue beyond ARM64 / 26H1 — the same failure occurs on 25H2 x64 at build 26200.9445 with KB5124008, i.e. the branch the majority of Windows users are on. Happy to run any diagnostic or instrumented build against this machine.</p><!--EndFragment-->
</body>
</html>

Same failure on x64, not only ARM64. Adding data since this issue currently
reads as ARM64-specific, which may be why it looks narrow.

Environment

• Windows 11 25H2, build 26200.9445, x64 (registry ProductName still

says "Windows 10 Pro" — known cosmetic artifact)

• Claude Desktop 1.49585.0 (same version as the original report)
• WSL 2.6.3.0, kernel 6.6.87.2-1, WSLg 1.0.71
• .wslconfig: only memory=8GB, swap=2GB, guiApplications=false
• Only registered distro: docker-desktop (Stopped). vmcompute, vmmem,

wslservice all running.

Symptom — identical string, on every device_bash call, command never runs:
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
[Note: mnt/SEO Project, mnt/claude-test failed to mount and cannot be reached
from this shell.]

Timeline points at the September cumulative update, same as the ARM64 case

• Through Aug 25 the shell worked normally (python scripts were run against the

connected folder via device_bash).

• Last update before that period: KB5123304 (Aug 11).
• Sep 9: KB5124008, KB5124007, KB5126052 installed.
• Shell broken the same day. The ARM64 report names KB5124012 — adjacent number,

same September wave.

Ruled out

• Not drive- or folder-specific. Working folder is on D: (NTFS, Fixed,

Healthy). I created an empty C:\claude-test, connected it as a second
folder, and the failure note then listed both folders as failed to mount —
zero shares attached, not a per-volume problem.

• Not a stale VM. Full app quit + wsl --shutdown (confirmed vmmem gone) +

relaunch → identical failure on the very first call.

• Not permissions or the folder grant. The file bridge

(device_list_dir / device_stage_files / device_commit_files) works
perfectly against the same folders throughout — it bypasses the VM. Only the
in-guest shell is dead, which matches "host attaches zero shares silently".

I have not attempted KB removal (production machine). Happy to run any
diagnostic that would help, and to A/B it if a specific KB is worth testing.

Host/guest pair for the failing boots, x64 Pro 25H2, 26200.9445 (KB5124008), app 1.49585.0.0.

Host, C:\ProgramData\Claude\Logs\cowork-service.log — identical on all four failing boots (07:39, 07:51, 07:59, 08:02 local), no error logged for the HCS call:

[VM] Plan9 share 'c' already configured identically (path=C:\ port=9902), skipping
[VM] Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
[VM] Sent plan9Shares notification (1 shares)

Guest, C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log, the 07:39 boot (04:39 UTC), in order:

[updater] mounted smol-bin device /dev/sdb1 at /smol/bin
[coworkd] session disk mounted successfully at /sessions
[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

After rolling KB5124008 back (26200.9168), the first boot logs the same attach request and the same notification — Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true → Sent plan9Shares notification (1 shares) — and Cowork starts and works. (The line before them reads Plan9 share added: c -> C:\ (port=9902, readOnly=false) instead of already configured identically, because the service had been restarted by the rollback reboot; that is registration, not the attach.) The host request is byte-for-byte the same in both states; what Windows does with it is not.

@MS-UVEC Note the block devices in the guest log above: smol-bin and the session disk attached and mounted normally, and only the 9p-over-vsock mount failed. Your read-only /dev/sdc may be a second effect of the same update rather than the same fault — worth keeping the two apart when this gets debugged.

@alexch-urb Log location for 1.49585.0: %APPDATA%\Claude\logs\cowork_vm_node.log and main.log stopped being written after the August app update on my machine too (last entries 2026-08-21). The live files are under C:\ProgramData\Claude\Logs\: coworkd\user-<SID>.log is the guest daemon's log mirrored to the host (UTC timestamps; it has the mounting Plan9 share / mounted N/M Plan9 shares lines), and cowork-service.log is the host service (local time). Three caveats: the service log is huge because of per-second polling; the mtime shown by Explorer/Get-ChildItem is stale while the files are open, so grep by content, not by date; and the guest mirror itself is not reliable — on my machine it has nothing after the 04:39 UTC boot, although the VM booted four more times, including the working boot after the rollback.

Select-String -Path "C:\ProgramData\Claude\Logs\coworkd\user-*.log" -Pattern "Plan9 share" | Select-Object -Last 10
Select-String -Path "C:\ProgramData\Claude\Logs\cowork-service.log" -Pattern "Plan9 share|plan9Shares" | Select-Object -Last 10

Same failure on Windows 11 x64 (release channel, not ARM64), app 1.49585.0.0 from Microsoft Store, Claude Code SDK 2.1.260 in the VM.

Symptoms are identical to the ones above: every device_bash call fails with sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared; main.log shows failed to mount ... as .auto-memory: source path ... is under Plan9 share "c" which is not mounted, and the retry fails with ensure user: user <session> already exists unexpectedly. device_list_dir / device_stage_files / device_commit_files keep working. The VM boots and reports healthy; add_plan9_shares logs nothing suspicious.

Trigger: the September cumulative update KB5124008 (OS build 26x00.9445), installed 2026-09-08. Before it (2026-08-30, app 1.40609) everything worked. App restarts, a full Windows reboot, and wsl --shutdown did not help; a plain WSL2 Ubuntu on the same machine still saw /mnt/d fine, so the Windows-side drive sharing itself was healthy.

Uninstalling KB5124008 and rebooting restored device_bash immediately, app version unchanged. So the regression is not ARM64-specific — the same September update wave breaks Plan9 share attachment on x64 release builds too.

<html>
<body>
<!--StartFragment--><h2 dir="ltr">A/B rollback confirmed on x64 — closing the caveat in my earlier comment</h2>

<p dir="ltr">Following up on my report above, where I noted <em>"Not attempted: KB removal"</em>. I have now done the rollback, and it confirms the cause on this machine.</p>

<p dir="ltr"><strong>Result:</strong> uninstalling KB5124008 took the build from <strong>26200.9445 → 26200.9168</strong>. <code>device_bash</code> works on the first boot after the reboot, with the app, SDK and VM bundle all unchanged (Claude Desktop 1.49585.0). Same controlled shape as @yuriyda's and @JonathanReams's rollbacks. Only Windows varied.</p>

<div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">--- shell alive ---
Projects
--- python ---
python3 OK</code></pre></div></div>

<h3 dir="ltr">Why this is a distinct data point</h3>

<p dir="ltr">The two earlier x64 rollbacks were on machines with the full Hyper-V role enabled. This one is not:</p>

<div dir="ltr">
Property | Value
-- | --
OS | Windows 11 25H2 x64, build 26200.9445 → 26200.9168
Machine | Lenovo laptop, AD-joined / managed
Full Hyper-V role | Not installed — vmms absent; only VirtualMachinePlatform + HypervisorPlatform enabled, vmcompute Running (Manual)
Windows Sandbox | Not enabled (Containers-DisposableClientVM = Disabled)
Filter drivers | Defender only (WdFilter); no third-party EDR/AV minifilter
App / SDK / bundle | 1.49585.0 / 2.1.260 / 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 — constant throughout

</div>

<p dir="ltr">So the defect does not depend on the Hyper-V role, on Windows Sandbox, or on any third-party filter driver. A stock 25H2 install with just the Virtual Machine Platform feature is enough to hit it.</p>

<h3 dir="ltr">Uninstall notes for others on 24H2 / 25H2</h3>

<p dir="ltr">The two obstacles reported in this thread did <strong>not</strong> apply here, so they are not universal:</p>

<ul dir="ltr">
<li>@yuriyda's blocker — Settings refusing to uninstall the LCU while <code>Containers-DisposableClientVM</code> is enabled — did not arise, since that feature was already Disabled. Worth checking it first either way.</li>
<li>@MS-UVEC's <code>0x800f0825 CBS_E_CANNOT_REMOVE</code> did not occur. The uninstall completed cleanly from <strong>Settings → Windows Update → Update history → Uninstall updates</strong>, with no CBS error.</li>
</ul>

<p dir="ltr" style="">The package identified on this machine, for anyone searching:</p>

<div role="group" aria-label="Code" tabindex="0" style=""><div><div></div></div><div><pre style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26</code></pre></div></div>

<p dir="ltr" style="">Note it carries the <strong>26100</strong> base even on 25H2 (build 26200), because 25H2 is an enablement package over 24H2 (<code>KB5054156</code> appears separately in the uninstall list). A <code>-like "RollupFix26200*"</code> filter finds nothing — search on <code>9445</code> instead.</p>

<p dir="ltr" style="">Sequence that worked, in this order: pause Windows Update → create a restore point → verify <code>Containers-DisposableClientVM</code> is Disabled → uninstall via Settings → reboot. Pausing updates first matters, or the LCU is simply reinstalled.</p>

<p dir="ltr" style=""><strong>KB5124008 alone</strong>, again: <code>KB5124007</code> (SSU, not removable by design) and <code>KB5126052</code> (.NET Framework) are both still installed here and Cowork works. That is a second machine corroborating @yuriyda's finding on that point.</p>

<h3 dir="ltr" style="">On the log location — thanks, and a possible separate defect</h3>

<p dir="ltr" style="">@yuriyda thank you, that answered my open question directly. Confirming the stale-log behaviour on a third machine: <code>%APPDATA%\Claude\logs\cowork_vm_node.log</code> has no entries after <strong>2026-08-19</strong> here (file mtime 2026-08-24), while the VM demonstrably booted many times since, including five failed launches on 2026-09-09 and the successful one after the rollback. Your point about the mtime being stale while the files are open is what defeated my earlier recursive scan — I was filtering by date, not content.</p>

<p dir="ltr" style="">That now makes three machines where the documented log path stops receiving writes after the August app update. For the maintainers: independent of the Plan9 regression, that is a reporting defect in its own right. It is the reason several of us in this thread could only offer timeline correlation instead of the host/guest log pair — the diagnostics existed, just not where the app said they were.</p>

<p dir="ltr" style="">I can attach the <code>C:\ProgramData\Claude\Logs\coworkd\user-&lt;SID&gt;.log</code> and <code>cowork-service.log</code> extracts covering the failing window if that is still useful now that @yuriyda has posted the host/guest pair.</p>

<h3 dir="ltr" style="">Standing request</h3>

<p dir="ltr" style="">The title still scopes this to ARM64. There are now, by my count, seven x64 reports in this thread and three independent x64 rollback confirmations, across Home, Pro and AD-joined managed installs. Anyone on 24H2 / 25H2 searching for <code>KB5124008</code> or <code>26200.9445</code> will not find this issue as titled.</p>

<p dir="ltr" style="">Rolling back a September security cumulative is not a workaround most managed environments can accept — mine can only carry it with updates paused and an explicit exception. An app-side mitigation, or at minimum surfacing the Plan9 mount failure in the UI instead of <code>SDK not verified</code> / <code>failed to mount</code>, would help a great deal.</p><!--EndFragment-->
</body>
</html>

OP update — ARM64 guest log has the same invalid argument as x64; three-state host/guest pair; and the two log paths are separate defects

Title widened as requested by @JonathanReams, @avincentx, @SpaceGrayMan and @alexch-urb — it now names both branches and both KBs. @alexch-urb your standing request is done; your comment was probably written before the change landed.

Two corrections to my own report, one new piece of evidence, and a consolidation.

1. Correction: it is not silent on the guest side

I characterised this as a silent failure with no error anywhere. That was wrong, and it was my mistake: I only had %APPDATA%\Claude\logs\cowork_vm_node.log. Following @yuriyda's pointer to C:\ProgramData\Claude\Logs\, my ARM64 machine logs exactly what x64 does:

2026/09/08 22:34:26 [hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
2026/09/08 22:34:26 [hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
2026/09/08 22:34:26 [hyperv] mounted 0/1 Plan9 shares
2026/09/08 22:34:26 [process:oneshot-<id>] optional mount <folder> (/mnt/.virtiofs-root/shared/c/Users/<user>/...) failed, continuing: source path ... is under Plan9 share "c" which is not mounted

(Guest log is UTC; my local time is UTC+8, so 22:34 UTC = 06:34 local, which is the first failure in my original timeline.)

The corrected claim is narrower and more useful: the failure is silent on the host side only. add_plan9_shares completes, HcsModifyComputeSystem returns no error, HCS logs Event 1001 Information — and the actual EINVAL appears only in the guest daemon log, which nothing in the UI points you at. ARM64 and x64 are one failure mode, not two.

2. New evidence: identical host request, three different outcomes

C:\ProgramData\Claude\Logs\cowork-service.log, same machine, app held at 1.49585.0.0 throughout:

| Local time | State | Host request |
|---|---|---|
| 2026-09-05 12:46:30 | pre-KB, working | Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true → Sent plan9Shares notification (1 shares) |
| 2026-09-09 01:48:48, 03:10:20, 07:43:30, 08:00:31, 08:05:48 | post-KB5124012, broken | byte-for-byte identical |
| 2026-09-09 08:35:07 | post-rollback, working | byte-for-byte identical |

This reproduces @yuriyda's finding on the other architecture and adds the pre-KB baseline: the same request succeeds before the update, fails after it, and succeeds again after rollback. flags=0x10, hasToken=true, port=9902, path=C:\ never change. The app is not sending anything different — the 9p-over-vsock mount inside the guest returns EINVAL only while the September cumulative is installed.

3. The two log paths are separate defects — and this machine is a counter-example on one of them

@alexch-urb counts three machines where "the documented log path stops receiving writes". Mine is not one of them, and I think the two logs need to be kept apart:

| Log | @yuriyda / @alexch-urb | This machine (ARM64) |
|---|---|---|
| %APPDATA%\Claude\logs\cowork_vm_node.log | stops after 2026-08-19 / 2026-08-21 | still being written — entries for every VM boot on 2026-09-09 (01:48, 03:10, 07:43, 08:00, 08:05) |
| C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log | stops after the 04:39 UTC boot | stops after 22:44:17 UTC, while cowork-service.log shows four further VM boots — including the post-rollback boot that worked |

So on the same app version, cowork_vm_node.log is dead on some machines and live on others. That is worth knowing before anyone concludes the log simply moved in 1.49585.0 — it did not move here.

The guest mirror truncation, by contrast, reproduces on both @yuriyda's machine and mine. That one matters most, because it is the only place the real EINVAL appears, and it is exactly the window a user needs when debugging.

4. Consolidated state of this thread

One release, three branch-specific KBs:

| KB | Branch | Build |
|---|---|---|
| KB5124012 | 26H1 | 28000.2954 |
| KB5124008 | 24H2 / 25H2 | 26100.9445 / 26200.9445 |
| KB5122880 | 23H2 | 22621.7582 |

Rollback A/B now confirmed independently on five machines, app version held constant in every case:

| Reporter | Arch | KB removed | Build change |
|---|---|---|---|
| this report | ARM64 | KB5124012 | 28000.2954 → 28000.2804 |
| @yuriyda | x64 | KB5124008 | 26200.9445 → 26200.9168 |
| @JonathanReams | x64 | KB5124008 | 26200.9445 → 26200.9168 |
| @olegbunin | x64 | KB5124008 | 26x00.9445 → prior |
| @alexch-urb | x64 | KB5124008 | 26200.9445 → 26200.9168 |

Not the .NET update. @yuriyda and @alexch-urb both removed only KB5124008, leaving KB5124007 (SSU) and KB5126052 (.NET) installed — Cowork works. Two machines agree.

Not dependent on Hyper-V role, Windows Sandbox, or filter drivers. @alexch-urb's rollback machine has no full Hyper-V role (vmms absent), Windows Sandbox disabled, and Defender's WdFilter as the only minifilter — just VirtualMachinePlatform + HypervisorPlatform + vmcompute. A stock 25H2 install is enough to hit this.

Further confirmations without rollback: @Harskov, @samtuominen (ARM64), @avincentx, @SpaceGrayMan, @MS-UVEC.

Three guest-side faces of the same update, worth keeping distinct when debugging:

1. Plan9 mount failed: invalid argument, mounted 0/1 — @yuriyda, @olegbunin, and this machine on ARM64
2. Session disk attaches read-only, guest never reaches the Plan9 step — @MS-UVEC
3. Nothing in the guest log at all, because the mirror stopped writing — @alexch-urb, and this machine after 22:44 UTC

The rollback is not available to everyone. @MS-UVEC cannot remove KB5124008 by any route (wusa → 0x800f0825; DISM /Remove-Package → CBS_E_CANNOT_REMOVE, blocked by a RetailDemo.OfflineContent.Content capability whose RTM version is missing; WinRE "Uninstall latest quality update" fails; no restore point). @SpaceGrayMan is on a production machine; @alexch-urb's is AD-joined and can only carry the rollback with updates paused and an explicit exception. For those users there is no workaround short of an app-side or guest-side change.

Uninstall notes for anyone attempting it, from @yuriyda and @alexch-urb — neither obstacle is universal, so check both:

• Settings may refuse to uninstall the LCU while Windows Sandbox is enabled: dism /online /disable-feature /featurename:Containers-DisposableClientVM, reboot, then uninstall.
• On 24H2/25H2 the package is Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26. It carries the 26100 base even on 25H2 (build 26200), because 25H2 is an enablement package over 24H2 — a *RollupFix*26200* filter finds nothing. Search on 9445.
• Order that worked: pause Windows Update → create a restore point → verify Containers-DisposableClientVM is Disabled → uninstall → reboot. Pausing first matters, or the LCU is reinstalled.

Blast radius is wider than local-agent mode. As @alexch-urb notes and I can confirm: cloud sessions linked to an affected machine lose device_bash too, because both use the same local VM. device_list_dir / device_stage_files / device_commit_files keep working throughout, so the folder grant and host-side file bridge are intact — only the share attach into the VM fails.

5. On the duration heuristic

@alexch-urb is right that add_plan9_shares duration is not a discriminator — for the record my original report says the same ("the 4-12ms duration is not diagnostic"), so we agree. Nobody should chase it.

6. What would help

1. Surface the guest's Plan9 mount failed in the UI. Right now the app reports the folder connected and the VM reachable; the user sees no Plan9 drive shares mounted from the shell, or — per @yuriyda — a misleading SDK not verified, which cost him four hours in the wrong direction.
2. Fix the guest log mirror so it keeps writing. It is the only place the real error appears, and it stops.
3. Say which log 1.49585.0 is supposed to write. cowork_vm_node.log is dead on at least three machines and live on mine, on the same app version. Several people in this thread could only offer timeline correlation because they looked in the documented place and found nothing.
4. Confirm the direction publicly. Since the host request is provably unchanged across working and broken states on two architectures, this looks like a Microsoft-side change in 9p-over-vsock handling. If that is Anthropic's read too, please say so — users on managed machines need to know whether to wait for an app update or escalate to Microsoft.

I have logs for all three states on ARM64 (pre-KB working, post-KB broken, post-rollback working) and can share them or run an instrumented build.

ARM64 + KB5124008 (25H2, 26200.9445): first data point for this branch/arch combination

_All ARM64 reports so far are on the 28000 branch (KB5124012); all KB5124008 reports are x64. Adding ARM64 on 25H2 with KB5124008. Same failure, same guest-side EINVAL._

Environment

Windows 11 25H2 ARM64, build 26200.9445. KB5124008 reached Installed state 2026-09-09 02:03:33 local (Windows Setup log, event 2; staged 01:27, reboot required 01:30). KB5126052 (.NET) installed in the same cycle. Previous CU KB5120998 on 2026-08-28.
Claude Desktop 1.49585.0.0 (MSIX arm64), Electron 44.2.0, Node 24.20.0, SDK 2.1.260.
VM bundle 2a762adfc2eea13eca0d113a2e6452ff00ae3f62, identical to OP. [warm] VM SHA matches current version, skipping at 01:14:58, so the guest image did not change.
App was already running before the update (VM warm check 01:14:58, vmClient loaded 01:25:35, no app update in between). App version, SDK and bundle are constant across the break; only the Windows build changed.
Host side, identical on 4 consecutive VM boots today (09:40, 12:12, 12:15, 12:31 local)

[VM:steps] vm_boot completed (160-299ms)
[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed (3-5ms)
[VM] Network status: CONNECTED
[VM:steps] sdk_install completed (2050-2489ms)
[VM] API reachability: REACHABLE
[vmOneShot] Running: bash [2 arg(s)] as rcw-...
[vm-stderr oneshot-] sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
No error anywhere on the host side.

Guest side, C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log (UTC), every boot after the update

2026/09/09 08:58:09 [hyperv] mounting Plan9 share "c" via vsock port 9902 at /mnt/.virtiofs-root/shared/c
2026/09/09 08:58:09 [hyperv] failed to mount Plan9 share "c": Plan9 mount failed: invalid argument
2026/09/09 08:58:09 [hyperv] mounted 0/1 Plan9 shares
2026/09/09 08:58:09 [process:oneshot-<id>] optional mount <folder> (/mnt/.virtiofs-root/shared/c/Users/<user>/<folder>) failed, continuing: source path ... is under Plan9 share "c" which is not mounted
Repeated identically at 09:11:37 UTC with two connected folders (one under the user profile, one at C:\ root), both reported as not mounted. Guest timestamps line up with the host-side bash failures at 11:58:09 and 12:11:36 local (UTC+3). Same failure mode as the OP's ARM64 guest log and the x64 reports: host request completes without error, guest 9p-over-vsock mount returns EINVAL.

Timeline

2026-09-03 last known good device_bash, same machine
2026-09-09 01:14:58 app warm check, VM SHA unchanged
2026-09-09 01:25:35 vmClient loaded, no bash calls
2026-09-09 01:27:07 KB5124008 Absent -> Staged (UpdateAgentLCU)
2026-09-09 01:30:27 reboot required
2026-09-09 02:03:33 KB5124008 Installed
2026-09-09 09:40:48 first VM boot on patched host, add_plan9_shares "completed" (4ms)
2026-09-09 11:50:01 first device_bash, fails
2026-09-09 12:12-12:32 three more VM boots, all identical
Ruled out

Not folder-specific: three folders fail identically, including a fresh test folder under the home directory containing a single 7-byte text file
Not path or whitespace related: a C:\ root folder, a cloud-synced folder and a home directory folder all fail the same way
Not timing: folder was granted before the session was created
Not fixed by app restart or full machine reboot
Folder grants persist; device_list_dir and file read/write via the file tools work. Only the in-VM shell is dead.
No rollback here. The machine processes personal data and the September security update stays in place. Same position as @MS-UVEC, @SpaceGrayMan and @alexch-urb: waiting on an app-side or guest-side change. Happy to provide full host and guest logs for the failing window or run an instrumented build.

ps. First time posting anything here so apologies for potentially crappy format, which, apart from this line was generated by Claude. So I blame Claude.

This is not ARM64-specific and not one KB

Not ARM64-only — same failure on x64 with KB5124008 (26200.9445)

Hitting this exact failure on x64, which suggests the scope is wider than the title implies.

CPU: Intel Core i7-1355U (x64)
Windows: 11 25H2, build 26200.9445, via KB5124008 — installed 9 Sep 2026, ~10:30 local
Same Patch Tuesday as KB5124012, different servicing branch

Identical signature to the original report: source path ... is under Plan9 share "c" which is not mounted, followed by the recovery path also failing with ensure user: user <session-name> already exists unexpectedly. Net result bash failed on resume, create, and re-resume. echo alive returns nothing.

Also matching: file tools are completely unaffected — reads, writes and glob against the same mounted folder worked normally throughout. Only the in-VM shell is dead.

Timeline: shell working before the update; failed on every attempt afterwards across three independent sessions spanning ~10 hours (14:00, 16:36 and 20:03 local), including scheduled-task sandboxes that spawn fresh. Not recovered by new sessions.

I have not attempted a rollback — KB5124008 is a security rollup and I'd rather not remove it, so I can't offer the A/B confirmation the original reporter did. But the trigger correlation and the identical error text seem worth adding.

<html>
<body>
<!--StartFragment--><p dir="ltr">Confirming the same failure on <strong>x64</strong>, with a different KB from the same September 2026 Patch Tuesday wave. The signature matches yours exactly, including the silent <code>add_plan9_shares</code> success.</p>
<p dir="ltr"><strong>Environment</strong></p>
<ul dir="ltr">
<li>Windows 11 Pro 25H2, build <code>26200</code> (servicing base <code>26100</code>)</li>
<li>Update: <strong>KB5124008</strong>, package <code>Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26</code></li>
<li>Claude Desktop <code>1.49585.0.0</code>, unchanged across the break</li>
<li>x64, not ARM64</li>
</ul>
<p dir="ltr"><strong>The silent success</strong></p>
<p dir="ltr">Five VM boots in <code>cowork_vm_node.log</code>, all identical:</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;">06:35:56 add_plan9_shares completed (33ms) &lt;- last boot BEFORE the update applied
09:04:46 add_plan9_shares completed (20ms)
11:10:44 add_plan9_shares completed (17ms)
11:23:54 add_plan9_shares completed (15ms)
11:27:52 add_plan9_shares completed (15ms)</code></pre></div></div></div>
<p dir="ltr"><code>[info]</code>, <code>completed</code>, no error, no HRESULT, while the guest reports zero shares. <code>create_network</code>, <code>create_vm_config</code> and <code>vm_boot</code> all complete cleanly too.</p>
<p dir="ltr">Guest error, including your secondary defect:</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/.../
outputs as outputs: source path ... is under Plan9 share "c" which is not mounted
create: RPC error -1: ensure user: user &lt;session-name&gt; already exists unexpectedly:
uid=1353 gid=1353</code></pre></div></div></div>
<p dir="ltr">The guest uid increments per session (1349 through 1353), so the recovery path fails on every new session as well.</p>
<p dir="ltr"><strong>Timeline</strong> (local, BST)</p>
<div dir="ltr">
Time | Event | Source
-- | -- | --
06:35:41 | VM boot, add_plan9_shares completed (33ms), no Plan9 error follows | app log
07:57:30 | KB5124008 reaches Installed state | DISM InstallTime
08:35:38 | rotated app log ends, zero Plan9 errors in the whole file | app log
08:52:12 | user triggers restart to update (event 1074, MoNotificationUx.exe) | System log
08:58:14, 08:59:29 | TrustedInstaller.exe initiates two further restarts as SYSTEM | System log
09:00:31 | final boot complete, update applied | System log
09:04:46 | first VM boot after the update, same silent success | app log
09:17:00 | first Plan9 error ever recorded | app log

</div>
<p dir="ltr">One VM boot before the update, clean. Every VM boot after it, broken.</p>
<p dir="ltr"><strong>Ruled out</strong></p>
<ul dir="ltr">
<li>Windows Defender: Controlled Folder Access, ASR rules, quarantine. No block or audit event referencing any Claude process, <code>vmwp</code> or <code>vmcompute</code> in the Defender operational log.</li>
<li>HP Wolf Security on a corporate-managed endpoint, including its Sure Click filesystem minifilter. A block surfaces an explicit HRESULT at or before <code>add_plan9_shares</code>, and cannot produce a success line.</li>
<li><strong>Administrator Protection</strong>, which KB5124008 begins rolling out and which looked like a plausible mechanism. It is off here: <code>TypeOfAdminApprovalMode = 1</code>, <code>EnableLUA = 1</code>, <code>ConsentPromptBehaviorAdmin = 5</code>.</li>
<li>Stale VM state. Five independent VM boots across five sessions, plus two full OS reboots at 11:07 and 11:26, all reproduce it identically.</li>
<li>App version. <code>1.49585.0.0</code> throughout, and your A/B holds it constant too.</li>
</ul>
<p dir="ltr"><strong>What I have not done</strong>: the rollback A/B. This is a corporate-managed machine and KB5124008 is a security cumulative, so removing it is not mine to decide. Your report stands as the direct causal proof; treat this as an independent x64 correlation on a second build line.</p>
<p dir="ltr">Also seconding your secondary point. <code>add_plan9_shares</code> reporting <code>completed</code> after attaching zero shares is what makes this expensive to diagnose: the only surfaced error is in the guest, and the shell needed to inspect the guest is the thing that is broken. A host-side assertion that the share count is non-zero, failing loudly at that step, would have saved the whole investigation.</p><!--EndFragment-->
</body>
</html>

Confirming this on x64, with one difference from the original report that may narrow it down.

Environment

• Windows 11 Pro, build 10.0.26200 (AMD64)
• KB5124008 installed 2026-09-09
• Claude Desktop 1.49585.0.0

Symptom
Scheduled tasks fail on every device_bash call — including a bare echo — with no Plan9 drive shares mounted, before touching any project files. device_list_dir keeps working, so the device connection itself is up.

The difference: interactive shells still work here.
In-app chat shells are unaffected on this machine. echo hello returns normally, and a full multi-step pipeline (Python, file writes, MCP calls) driven from chat completed successfully on the same day, in the same app, minutes after a scheduled run failed. Only scheduled/unattended runs fail.

That suggests the regression may be specific to the path scheduled runs take to reach the device shell, rather than Plan9 share attachment failing across the board.

Also ruled out on this machine

• Reproduces identically on two separate accounts on the same PC — one stock install, one launched with its own --user-data-dir — so profile isolation is not a factor.
• Clearing and re-provisioning the Cowork VM payload (%APPDATA%\<profile>\claude-code-vm) did not help; the freshly downloaded VM behaves the same.
• Reconnecting the working folder and deleting/recreating the scheduled tasks did not help.

Timeline

• Last successful scheduled run: 2026-09-08 10:30 local
• First failure: 2026-09-09 10:30 local, after KB5124008 installed the same morning

Haven't rolled the KB back yet. Happy to A/B test it if that would help confirm.

x64 confirmation with a same-day, same-app-version before/after pair (no rollback attempted)

Environment: Windows 11 Pro 25H2 x64, build 26200.9445 via KB5124008 (staged 01:30, Installed 03:38, update reboots at 03:31 and 03:37 local on 2026-09-09). Claude Desktop 1.49585.0.0 (MSIX, installed 2026-09-08 20:38, i.e. before the break), Electron 44.2.0, Node 24.20.0, SDK 2.1.260 in the guest. Only Windows Defender, no domain/MDM, no WSL policies.

What makes this data point useful: the same app version and same VM bundle booted the VM both before and after the update reboot on the same day, so the app update is excluded as the variable.

Guest log (C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log, UTC), last boot before the update reboot — 01:25:33 UTC = 03:25 local:

[coworkd] detected Hyper-V host, loading vsock/9p modules
[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

Windows then rebooted for KB5124008 at 03:31. Every VM boot since (10:01, 12:36, 12:47 local) fails: every oneshot process the host launches exits with code 1 (yesterday: 128 × code=0, 2 × code=1; today after the reboot: 0 × code=0, 11 × code=1), and the app-side error is the familiar one:

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

Host side (cowork-service.log) is identical before and after, no error:

[VM] Adding Plan9 share via HcsModifyComputeSystem: name=c path=C:\ port=9902 flags=0x10 hasToken=true
[HCS] HcsModifyComputeSystem returned: hr=0x0
[VM] Sent plan9Shares notification (1 shares)

Hyper-V host binaries replaced by this servicing wave (all dated 2026-09-08 20:29 in System32): vmwp.exe 10.0.26100.8875, vmcompute.dll 10.0.26100.9444, computecore.dll / vmdevicehost.dll / vmwpctrl.dll 10.0.26100.9278, p9np.dll 10.0.26100.9278.

Also matching earlier reports: file tools (read/write into the connected folders) keep working, only the in-VM shell is dead; plain WSL2 Ubuntu on the same machine still mounts /mnt/c fine (type 9p ... trans=fd), so hvsocket/Hyper-V in general are healthy and the breakage is specific to the HCS Plan9 share path used by the Cowork VM.

Side note, unrelated and pre-existing since April: a second share for a Google Drive volume (g, FAT32) has always failed with Plan9 mount failed: file exists, while c mounted fine until this update.

<html>
<head>

<title></title>
<meta name="generator" content="LibreOffice 26.2.1.2 (Windows)"/>
<style type="text/css">
@page { size: 21cm 29.7cm; margin: 2cm }
th p { font-weight: bold; text-align: center; orphans: 0; widows: 0; background: transparent }
td p { orphans: 0; widows: 0; background: transparent }
pre { background: transparent }
pre.western { font-family: "Liberation Mono", monospace; font-size: 10pt }
pre.cjk { font-size: 10pt; font-family: "NSimSun", monospace }
pre.ctl { font-family: "Liberation Mono", monospace; font-size: 10pt }
h3 { margin-top: 0.25cm; margin-bottom: 0.21cm; background: transparent; page-break-after: avoid }
h3.western { font-family: "Calibri", sans-serif; font-weight: bold; font-size: 14pt }
h3.cjk { font-size: 14pt; font-family: "Microsoft YaHei"; font-weight: bold }
h3.ctl { font-family: "Lucida Sans"; font-size: 14pt; font-weight: bold }
p { line-height: 115%; margin-bottom: 0.25cm; background: transparent }
</style>
</head>
<body lang="en-GB" link="#000080" vlink="#800000" dir="ltr"><p>Confirming
this on <b>x64</b>, where the original report is ARM64. Same error
string, same app version, and the timeline points at the same Patch
Tuesday.</p>
<h3 class="western">Environment</h3>
<ul>
<li><p><b>Claude desktop:</b> 1.49585.0 · <b>Electron:</b> 44.2.0 ·
<b>Node:</b> 24.20.0</p></li>
<li><p><b>OS:</b> Windows 11, <b>x64</b> (not ARM64)</p></li>
<li><p>Cowork mode, two local folders connected to the session</p></li>
</ul>
<h3 class="western">Symptom — identical to the original report</h3>
<p>Every call into the sandboxed shell fails immediately, before
running anything:</p>
<pre class="western" style="background: #e1e1e1; margin-bottom: 0.5cm">sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared</pre><p>
with a note naming both connected folders and saying they &quot;failed
to mount and cannot be reached from this shell&quot;. No command runs
at all.</p>
<h3 class="western">Timeline, and it brackets the September Patch
Tuesday</h3>
<ul>
<li><p><b>6 September — working.</b> An <font face="Liberation Mono, monospace">npm
install</font> was executed from inside the mount on that date.
Evidence: the resulting <font face="Liberation Mono, monospace">package-lock.json</font>
records the project name as the <i>sandbox mount's</i> name rather
than the Windows folder name, which is what npm derives when it runs
in that directory.</p></li>
<li><p><b>8 September — Windows updates installed.</b> <font face="Liberation Mono, monospace">Get-HotFix</font>
shows three, all dated 8 September: <b>KB5124008</b> (the September
2026 cumulative security update, OS builds 26100.9445 / 26200.9445),
<b>KB5126052</b> (.NET Framework 3.5 and 4.8.1), and <b>KB5124007</b>.</p></li>
<li><p><b>9 September — failing</b>, on the first shell call of
the day, and every one since.</p></li>
</ul>
<p>This report names <b>KB5124012</b> on ARM64. I have <b>KB5124008</b>
— the same September 2026 Patch Tuesday release, different SKU. <b>So
the trigger may be the September cumulative update generally rather
than one KB number</b>, which would matter for anyone searching for
the exact number given here and not finding it.</p>
<h3 class="western">The diagnostically useful part: everything except
the shell still works</h3>
<p>This is not a broken connection to the machine. Throughout the
same session, all of the non-shell bridge operations succeed against
both folders: directory listing, staging files from the machine into
the session, committing files back to it, and the device-info call.
Twelve files were written to a connected folder and every one
verified byte-identical afterwards. So the host-to-session link is
healthy — what is missing is specifically the share exposed to the
shell.</p>
<h3 class="western">Both connected folders fail identically, which
rules out the usual explanations</h3>

  | Folder A | Folder B
-- | -- | --
Path shape | C:\<top-level>\<project> | C:\Users\<user>\Documents\<...>\<project>
Inside the user profile? | No | Yes
Contents | ~700 files, many subfolders | 2 entries
Result | failed to mount | failed to mount

<p><br/>
<br/>

</p>
<p><b>Not path location</b> — one is under the user's Documents
folder and one is not, and both fail. <b>Not special characters</b> —
neither path contains a space, a parenthesis or any punctuation. <b>Not
folder size or content</b> — one holds ~700 files, the other 2. <b>Not
a missing grant</b> — both are reported as connected, and the file
tools read and write them successfully.</p>
<h3 class="western">Remediation attempted, none effective</h3>
<p>New sessions (several); a full quit including ending the surviving
<font face="Liberation Mono, monospace">Claude</font> process in Task
Manager; a laptop reboot; and <b>Windows Settings → Apps →
Installed apps → Claude → Advanced options → Repair</b>. The
app version was unchanged afterwards and the error is byte-for-byte
identical. Consistent with this being host-side rather than an app
regression — Repair reinstalls the app, and on this evidence the
app was never the problem.</p>
<p><i>(Note for anyone following the standard advice: this build
shows no system-tray icon, so &quot;right-click the tray icon and
Quit&quot; does not apply. Close the window, then end the surviving
processes in Task Manager.)</i></p>
<h3 class="western">What I have NOT done</h3>
<p><b>I have not run the A/B rollback</b>, because removing a
cumulative update means removing a security rollup, and the
workaround costs me only speed. So this is a correlation with a
plausible mechanism and a tight date match — not a causal
confirmation on x64.</p>
<h3 class="western">Impact and workaround</h3>
<p>No data loss; a capability outage. Nothing can be <i>run</i>
against the connected folder from the session — integrity checks,
generators, a document build. Files remain fully readable and
writable. The workaround is to copy inputs into the session's cloud
container, run them there, and copy outputs back. It works, it is
slower, and it puts two copies of every file in play.</p>
<h3 class="western">One adjacent observation, possibly unrelated</h3>
<p>In folder A, <font face="Liberation Mono, monospace">node_modules\.bin</font>
contains exactly two entries and both are <b>POSIX symlinks</b>,
created by that 6 September <font face="Liberation Mono, monospace">npm
install</font> run inside the Linux mount. A Windows-side <font face="Liberation Mono, monospace">npm
install</font> would have written <font face="Liberation Mono, monospace">.cmd</font>
shims instead. Folder B contains no symlinks and fails identically,
so this is almost certainly not the mount cause — but it has a
separate consequence worth knowing: <b>a file-backup tool on the host
began reporting errors on exactly those two files</b>, because it
cannot process them.</p>
<hr/>

<p><i>Paths, machine name and project name replaced with
placeholders. Nothing technical turns on the literal names — the
two-folder comparison above depends only on whether a folder sits
inside the user profile. Session identifiers can be supplied
privately if that would help correlate with server-side logs.</i></p>
<p><br/>
<br/>

</p>
</body>
</html>^@

Rollback A/B done on this machine — correcting my comment above, which said I
hadn't attempted it.

Removed the September cumulative (the RollupFix package for 26200.9445) with
Remove-WindowsPackage -Online, rebooted, and device_bash came up on the very
first call. App, SDK and VM bundle unchanged (1.49585.0). Connected folders mount
at $HOME/mnt/<folder>, python 3.10.12 in the guest, files read and written
normally. Only Windows varied — same controlled shape as the OP.

That makes a third independent x64 rollback confirmation alongside @yuriyda and
@JonathanReams.

Second data point, x64 / 25H2, same September release wave — different KB, same symptom, and
the rollback reproduces on x64.

Your ARM64 rollback proved it for KB5124012. Removing KB5124008 on our x64 machine restored the
sandbox with the Claude app version held constant, so this is a second independent single-machine
proof on the other architecture rather than mere corroboration.

Host: Windows 11 Pro x64, 25H2, build 26200. Update: KB5124008 (2026-09 cumulative for
24H2/25H2, -> build 26200.9445) plus SSU KB5124007, installed 2026-09-09. Previous patch KB5123304,
2026-08-12. KB5124008 is the 26100/26200-family sibling of your KB5124012.

The same two errors, same wording, differing only in the session uid:

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/.../uploads
as uploads: source path ... is under Plan9 share "c" which is not mounted

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

-> bash failed on resume, create, and re-resume

Two differences worth naming, and the second may be the useful one. First, the session uid:
yours 1926, ours 1001 — ours was 1162 on the first three calls and 1001 on the three after a
VM-bundle wipe, so the numbers are independently produced rather than copied across.

Second: our LOCAL sessions never emit your sandbox-helper: no Plan9 drive shares mounted under
/mnt/.virtiofs-root/shared line — they name share c directly, as above — while our CLOUD session
emitted it verbatim, on the same machine and from the same fault. So the two messages look like
variants of one condition surfacing at different points rather than two separate states: no Plan9
drive shares mounted and share "c" which is not mounted may be the same thing seen from either
side of the attach. Worth a maintainer's eye, since having both forms from one machine is something
your report had no way to show.

Timeline: six scheduled tasks requiring the shell all ran clean on Sunday 2026-09-06, and a
2026-09-07 session executed scripts and installed a package. First failure after the 2026-09-09
update. Two reboots that morning as the update finalised.

Cross-machine A/B (both x86_64; neither machine had a September cumulative before 2026-09-09 —
A took KB5124008, B has not):

| Machine | KB5124008 | Claude Desktop | device_bash |
|---|---|---|---|
| A | installed 2026-09-09 | 1.49585.0.0 | FAILS — 6/6 calls |
| B | absent (August state) | 1.37937.1.0 | WORKS — all three mounts present |

This cross-machine table is the weaker of the two proofs and is kept only as corroboration; the
single-machine rollback below supersedes it, holding the app version constant on one box.

Also excluded here, in case it saves anyone time:

• Cloud vs local session mode — fails in both. The two message forms are the difference described

above, not two separate faults.

• Full Delete Cowork VM Bundle and Restart -> genuinely fresh VM (session uid 1162 -> 1001) and

the fault persisted. Independent confirmation of your VM-image-hash finding by a different route.

• Claude app restart — the VM was resumed rather than rebuilt (uid unchanged) and the fault persisted.
• VirtualMachinePlatform Enabled; Hyper-V and WSL Disabled and never required.
• Third-party endpoint protection — its log records only URL blocks and has never logged a

Claude-related block; the VM-host process shows the same Monitoring state it has had at every
app version through months of healthy operation.

Strong +1 on your secondary point. add_plan9_shares logging completed while attaching zero
shares is what makes this expensive to diagnose: the only error surfaces inside the guest, and the
shell you would use to investigate is the thing that is broken. That silent success is the whole
difficulty.

Rollback A/B — x64, 2026-09-09. Same machine, Claude Desktop held at 1.49585.0.0 throughout.

• Before (KB5124008 installed): six consecutive failures — three at session uid 1162, three at

1001 after a VM-bundle wipe — all with the Plan9 share "c" which is not mounted /
ensure user ... already exists unexpectedly pair above.

• After (KB5124008 removed, machine rebooted): probe-ok, uid 1001, x86_64, all four drive

shares present, sandbox writes working. Get-HotFix confirms KB5124008 absent.

Put plainly: six consecutive failures before the removal; every call since has succeeded.

Two caveats, both worth stating rather than smoothing over. Tested in one direction only — the
update was removed and the fault cleared; we have not re-applied it to confirm the fault returns, so
unlike yours this is a removal proof rather than a both-directions reproduction. And after the rollback KB5121003 appears in machine A's Get-HotFix dated to the rollback day. I have not verified what that update is, and both listings were truncated to the five most recent, so I make no claim about the servicing mechanism — only that machine B carries the same KB, so the two machines' patch states converged rather than A reaching a clean-room state.

<html>
<body>
<!--StartFragment--><html><head></head><body><h2>x64 confirmation: same failure on Windows 11 25H2 (KB5124008, build 26200.9445)</h2>
<p>Adding an <strong>x64</strong> data point to this ARM64-only report. Same Patch Tuesday, different KB, identical failure signature — <code>add_plan9_shares</code> reports success and attaches nothing.</p>
<h3>Environment</h3>

  |  
-- | --
OS | Windows 11 Pro 25H2, OS Build 26200.9445
Update | KB5124008, released 2026-09-08 (x64 counterpart of ARM64's KB5124012)
Arch | x64 (Lenovo ThinkBook)
Claude Desktop | 1.49585.0.0 (Microsoft Store / MSIX, Claude_1.49585.0.0_x64__pzs8sxrjxfjjc)
Electron / Node | 44.2.0 / 24.20.0
VM bundle | 2a762adfc2eea13eca0d113a2e6452ff00ae3f62

<p>Roughly 70 minutes separates the last good run from the first failure, on the morning after the update landed.</p>
<h3>Ruled out</h3>
<p>Each of these was tested and reproduced the identical error:</p>
<ul>
<li><strong>Folder-specific causes.</strong> Four folders connected and tested independently: an OneDrive path with a leading <code>!!!!</code> prefix, a plain-named OneDrive folder, an empty folder outside OneDrive, and an <code>AppData\Local</code> folder. All four fail the same way; the guest reports zero shares regardless.</li>
<li><strong>OneDrive / reparse points.</strong> The non-OneDrive folder fails too.</li>
<li><strong>App restart</strong> (×3) and <strong>full OS reboot</strong> (×2).</li>
<li><strong>Forced SDK re-download.</strong> Renamed <code>claude-code-vm\2.1.260</code> → <code>.bak</code>; next start logged <code>download_and_sdk_prepare completed (2512ms)</code> (vs 3ms cached), confirming a genuine fetch. The verify step failed identically afterwards.</li>
<li><strong>WSL.</strong> <code>wsl --status</code> → Default Version 2; <code>wsl --update</code> → "most recent version already installed".</li>
<li><strong>Third-party AV.</strong> None installed; Defender only.</li>
<li><strong>Check Point Endpoint Connect VPN.</strong> Stopping the service made things <em>worse</em> — the VM service itself then failed to start (<code>VM service not running</code>), with <code>ENOENT: connect to \\.\pipe\cowork-vm-service failed</code> looping every second until a reboot restored it. Not causal, but worth flagging as a misleading side path for anyone bisecting this.</li>
</ul>
<h3>Scope of impact</h3>
<p>Host-side file access is unaffected — directory listing, staging and committing files all work normally throughout. The failure is confined to the guest's view of the shares, so anything routed through <code>device_bash</code> is dead while everything using the host-side file bridge continues to function. That makes the bug easy to under-report: most workflows keep working, and only in-VM shell work breaks.</p>
<h3>Note on the documented workaround</h3>
<p>Removing the update restores functionality, but for x64 users the September cumulative closes two elevation-of-privilege vulnerabilities Microsoft lists as actively exploited (CVE-2026-85880, CVE-2026-81963). That makes rollback a poor trade on production machines, so an app-side workaround for the changed Windows behaviour would be the far more useful fix here.</p>
<p>Happy to run any diagnostic that helps narrow it — including an A/B rollback on this x64 machine if that would confirm the parallel to the ARM64 case.</p></body></html><!--EndFragment-->
</body>
</html>

Third platform, third KB, same failure. Windows 11 25H2 x64, and neither KB5124012 nor KB5122878 is installed here.

| | |
|---|---|
| OS | Windows 11 25H2 |
| Build | 26200.9445 |
| Architecture | x64 |
| Claude desktop app | 1.49585.0 |
| Electron / Node | 44.2.0 / 24.20.0 |

Identical error, every call, no command ever runs:

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

A scheduled task on this machine logged a fuller guest-side form the same day:

source path ... is under Plan9 share "c" which is not mounted
ensure user: user already exists unexpectedly

Why this is worth adding. With #93071 (Windows 10 22H2 x64, KB5122878) that is now three Windows versions, two architectures and three different KBs producing one failure mode. KB5124012 cannot be the cause in the general case. Either the September 2026 servicing branch changed something common across all of them, or the defect in add_plan9_shares was already present and these updates expose it. The second fits better, given the older reports at #31988, #31520, #32828, #25293, #43896 and #72685.

One timing detail that may narrow it. This machine broke on 8 Sep, but its September security update (KB5124008, 26200.9445) shows as installed on 9 Sep. The only change in Windows Update history before the break is KB5120998, the optional 2026-08 Preview Update (26200.9278), installed 7 Sep. If that holds up elsewhere, the regression may sit in the August preview branch that the September cumulative updates then carried forward, rather than in Patch Tuesday itself. I have not A/B tested this: KB5120998 is superseded by KB5124008, so removing it means giving up a current cumulative security update, which is not a test worth running on a working machine.

Timeline, from scheduled task run logs on this machine:

| Date | Event |
|---|---|
| 2 Sep | Scheduled task ran fine, 10 successive device_bash calls |
| 3 Sep | Second scheduled task ran fine, produced its output |
| 7 Sep | KB5120998 installed (2026-08 Preview, optional) |
| 8 Sep | First failure. Every call since is identical |
| 9 Sep | KB5124008 + KB5126052 installed, full Windows shutdown and restart. Still failing |

A full Windows restart does not clear it. Worth stating plainly, since app restart is the usual first suggestion and neither that nor a host reboot helps here.

Confirming what #93071 reports about scope, on this machine too: the whole device bridge works except the shell. get_device_info, device_list_dir, device_stage_files and device_commit_files all behave normally.

And one diagnostic detail I have not seen mentioned. device_request_folder_access also succeeds. I granted 21 folders in one session and every grant returned success while the shell was completely unusable. A session therefore appears to start correctly and only fails at the first command, which is why this reads as a folder permission problem when it is not one. Strongly seconding the request in both issues to surface "host share attachment returned zero shares" at VM start rather than the guest mount error per command.

Impact here: two scheduled tasks and one monthly task dead since 8 Sep. One fired on 9 Sep, detected the missing shell, logged a skip and correctly wrote nothing. Stage, edit in the container, commit back is a working manual substitute but does not scale.

Same failure on x64, not ARM64, and with a different September KB. Adding it here rather than opening a separate issue since the mechanism looks identical, but the environment differs on both axes — flag if you'd prefer it split out.

Environment

| | |
|---|---|
| Platform | Windows 11 25H2, x64 (not ARM64) |
| OS build | 26200.9445 |
| Update installed | KB5124008, installed 2026-09-09 (released 2026-09-08) |
| Claude Desktop | 1.49585.0, installed 2026-09-08 |
| Electron / Node | 44.2.0 / 24.20.0 |

Symptom

device_bash fails immediately on every call, exit code 1:

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

[Note: mnt/Projects 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.]

No command executes — a bare echo alive returns the same error, so the helper is aborting before the shell starts.

What still works

• device_list_dir reads the connected folder normally.
• device_stage_files / device_commit_files are unaffected.
• A local Filesystem MCP server (stdio) is announced and working.

So the folder grant itself is fine at the app level. get_device_info returns the connected folder correctly:

"connectedFolders": ["C:\\Users\\andre\\Projects"]

The failure is confined to the share attachment into the VM.

Timeline

• 2026-09-08, daytime — working normally.
• 2026-09-08 — Claude Desktop 1.49585.0 installed (per Installed apps).
• Overnight 08→09 Sept — machine rebooted unprompted; KB5124008 recorded as installed 2026-09-09.
• 2026-09-09, evening — device_bash failing as above.

Because the app update and the Windows update both took effect at the same restart, the timeline alone does not separate them. Issue #92958's A/B test holding the app at 1.49585.0.0 — the same build I'm on — is what points away from the app.

What has and hasn't been ruled out

Ruled out:

• Device connectivity — the device is reachable; get_device_info and device_list_dir respond.
• No folder connected — the fault persists with C:\Users\andre\Projects granted and confirmed present in connectedFolders.
• Restart — multiple restarts of both the app and the machine, no change.
• WSL — WSL was not installed on this machine at all when the fault appeared. It has since been installed, with no effect. Worth recording: the failure occurs on a machine with no WSL, so anything WSL-dependent is not the path.

Not ruled out — no A/B rollback performed. I have not uninstalled KB5124008 or rolled back the app, so I cannot claim the controlled evidence #92958 has. This is a timing correlation plus a matching error signature, nothing stronger.

Why this may be worth having

#92958 is reported and confirmed on ARM64 under KB5124012. This is x64 under KB5124008. If both are the same underlying regression, the trigger is broader than one KB or one architecture, which changes what a fix has to cover.

24H2 x64 confirmation — build 26100.9445 (KB5124008), rollback A/B

Adding the 24H2 branch: the x64 reports above are all 26200.9445 (25H2); this machine is 26100.9445 (24H2). Same failure, same fix.

• Windows 11 24H2 x64, build 26100.9445. KB5124008 installed 2026-09-09 09:24:25 local, broke the same day. Claude desktop 1.49585.0, unchanged throughout.
• Symptom identical to OP: every device_bash call dies before the shell runs with sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared. device_list_dir / device_stage_files / device_commit_files unaffected.
• Rollback A/B: Remove-WindowsPackage -Online -PackageName 'Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26' + reboot → both connected folders mount, device_bash fully functional.

Two things this machine narrows down:

• Hyper-V role and Windows Sandbox are disabled here (VirtualMachinePlatform Enabled, HvHost + vmcompute Running; Microsoft-Windows-Subsystem-Linux and HypervisorPlatform both Disabled). @yuriyda had Hyper-V enabled, so the bug does not depend on it — and the LCU uninstalled from PowerShell without needing the Windows Sandbox workaround.
• Not path-related. Original folder is under OneDrive with a Cyrillic name; a second folder C:\ClaudeTest (ASCII, outside OneDrive) failed identically.

App restart, new session and a full power cycle made no difference before the rollback.

Confirming the same failure on Windows 11 Pro x64, build 26200.9445, Claude Desktop 1.49585.0.0 (Microsoft Store), Claude Code 2.1.260 in the VM.

Trigger: September 2026 cumulative update KB5124008 (x64 equivalent of KB5124012), installed 9 Sep 00:53, reboot 02:31. The same app version and VM bundle (2a762adf) ran 16 device_bash calls cleanly between 23:22 and 01:05 before the update; every VM built after it (02:33 auto-relaunch, and 14:32 after a full Exit/relaunch with a fresh instance ID) fails identically:

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

device_list_dir / device_stage_files / device_commit_files still work. WSL is not installed on this machine, so it is not a WSL interaction. vmcompute.exe and vmswitch.sys were replaced by the update (file times 9 Sep 01:46).

The uninstall workaround is not available here: Settings fails with 0x800F0825 and DISM /Remove-Package on Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26 reports "Permanent package cannot be uninstalled". No restore points. So x64 users who cannot roll back have no workaround at all until the app is fixed.

Confirming this on x64 with the 25H2 equivalent of the same Patch Tuesday cumulative update.

Environment

• OS: Windows 11 Home 25H2, build 10.0.26200, x64 (Intel i5-8265U, 8 GB RAM)
• Claude Desktop: MSIX package Claude_pzs8sxrjxfjjc (installed from claude.ai download)
• Claude Code SDK inside VM: 2.1.260
• Windows update installed 2026-09-09: KB5124008 (2026-09 cumulative update for Windows 11 24H2/25H2), plus KB5126052 (.NET) — the latter is unrelated
• No VPN, no third-party antivirus, Defender Controlled Folder Access disabled, VirtualMachinePlatform Enabled, CoworkVMService Running, vmmem/vmwp/cowork-svc alive

Symptoms (identical to the issue description)

First error shown in UI right after the Windows update reboot:

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

(.verified exists on the host; the guest simply cannot see drive C.)

After regenerating sessiondata.vhdx the error becomes the one in this issue:

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/<org>/<user>/<session>/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=1001 gid=1001

Also intermittently: VM service not running, VM connection timeout after 60 seconds. Get-NetAdapter shows no cowork-vm-nat adapter and Get-NetNat is empty while broken.

Ruled out (all tried, no effect)

Reboot (x3), reinstall workspace from the UI, full app uninstall/reinstall, renaming claude-code-vm and vm_bundles to force re-download, renaming sessiondata.vhdx, icacls SYSTEM:(OI)(CI)F on vm_bundles and claude-code-vm, restarting CoworkVMService.

Fix (A/B, app version constant)

Uninstalling KB5124008 via Settings → Windows Update → Update history → Uninstall updates, then reboot: echo hola works immediately in existing and new Cowork sessions. Windows Update paused to prevent reinstallation.

Collateral damage worth flagging

The in-app error text and the assistant inside Cowork both recommended "reinstall Claude". On an MSIX install, uninstalling deletes %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude including all local Cowork sessions (no recycle bin). I lost every Cowork chat and recovered 51 of them only because a VSS restore point happened to exist. Please: (1) do not suggest reinstalling for Plan9/virtiofs mount failures, and (2) warn before uninstall that local sessions will be deleted, or back them up automatically.

Confirming on x64 — same bug, different KB (KB5124008, build 26100.9445)

Hit this today on Windows 11 x64, so this isn't ARM64-specific. Same silent failure, same Claude Desktop version (1.49585.0), fixed by the equivalent rollback.

Environment: Windows 11 x64, build 26100.9445 → rolled back to 26100.9278. Claude Desktop 1.49585.0, Electron 44.2.0, Node 24.20.0.

Trigger: KB5124008 (the x64 September 2026 cumulative, OS build 26100.9445) installed 2026-09-08 22:16. Cowork broke at the next VM start, 09:12 the following morning.

Symptoms — identical to the original report:

sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared on every device_bash call, and a downstream consequence worth noting since it's a distinctive fingerprint: RPC error -1: SDK version 2.1.260 not verified at /mnt/.virtiofs-root/shared/c/Users/<user>/AppData/.../claude-code-vm/2.1.260/.verified. The SDK is verified by reading it back through the C: drive share, so with the share missing it can never verify — a symptom, not a separate fault, but it's what most users will see first.

The failure onset in cowork_vm_node.log:

09:12:18  [VM:steps] add_plan9_shares completed (14ms)
09:13:18  [error] [VM:start] Connection timeout, last completed step: add_plan9_shares
09:13:18  [VM:start] Auto-reinstalling workspace after startup failure
09:13:40  [VM:steps] add_plan9_shares completed (6ms)
09:44:19  [warn] sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

Every subsequent VM start logs add_plan9_shares completed in 0–6ms with no error while the guest sees no shares. The silent success is the real bug — nothing surfaces this as a failure, the app reports VM already connected throughout, and the auto-reinstall recovery path produces an equally broken workspace, so restarts appear to "work" while nothing does.

device_list_dir / device_stage_files / device_commit_files were unaffected the whole time, and folder grants persisted.

Ruled out before finding this issue: VirtualMachinePlatform / HypervisorPlatform / WSL features all enabled; hypervisorlaunchtype Auto; no WSL distro installed; PC reboot; app restart; app Repair; CoworkVMService (found Stopped at one point — restarting it to Running/Automatic did not fix it, so that's a red herring); renaming vm_bundles to force a clean VM image rebuild (app re-provisions correctly, still no share).

Fix, confirmed:

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

Reboot, and device_bash works immediately on the same Claude Desktop version. Windows updates then need pausing or the KB reinstalls.

Gotcha for anyone following along: Remove-WindowsPackage fails with Class not registered under PowerShell 7 — the DISM module's COM interfaces don't register under pwsh. Get-WindowsPackage also silently returns nothing there. Use DISM.exe directly, or Windows PowerShell 5.1.

Reproduced on x64, not only ARM64. Windows 11 25H2 x64, build 26200.9445, cumulative update KB5124008 (installed 2026-09-09). Claude Desktop 1.49585.0. Identical symptom: every device_bash call fails before executing anything with sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared, for OneDrive-synced and plain local folders alike (tested three folders). Folder listing and file commit via the bridge kept working. Uninstalling KB5124008 and rebooting fixed it immediately; no changes to the app or VM bundle. So the x64 counterpart of KB5124012 triggers the same host-side failure.

Confirmation of #92958 on x64: KB5124008 (build 26200.9445) breaks Plan9 shares

Same failure as #92958, but on x64 and with the x64 counterpart of that
update. A/B rollback confirms it in both directions.

Environment

| | |
|---|---|
| Claude Desktop | 1.49585.0 (Electron 44.2.0, Node 24.20.0) |
| OS | Windows 11 25H2, build 26200, UBR 9445 |
| Arch | x64 (not ARM64) |
| Host | Windows 11 guest VM on a KVM-based hypervisor, nested virtualization enabled |
| Trigger | KB5124008, September 2026 cumulative update |
| Package | Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26 |
| Installed | 2026-09-09 03:18:13 (unattended maintenance window) |

Connected folders at the time of testing:

• Z:\projectdata — mapped network drive (SMB, \\fileserver\share\projectdata)
• C:\Users\<user>\Downloads — purely local NTFS

Timeline

Worked without issue until 2026-09-08. KB5124008 installed unattended at
03:18 on 2026-09-09. Broken from that point on. Claude Desktop version
unchanged across the whole window.

Symptom after the update

device_bash, for every connected folder — including the purely local one:

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

[Note: mnt/projectdata, mnt/Downloads failed to mount and cannot be reached
from this shell.]

Not a single share attached, exactly as described in #92958. $HOME/mnt/ empty.

Tool behaviour in this state:

| Tool | Local folder (C:) | Mapped drive (Z:) |
|---|---|---|
| device_list_dir | works | works, full listing with sizes and mtimes |
| device_stage_files | works | fails: Could not stat Z:\projectdata\notes.md |
| device_bash | fails, not mounted | fails, not mounted |

Rollback

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

Reboot. Result: all shares mount again, including the mapped network drive.

$HOME/mnt/
  Downloads
  projectdata

$ head notes.md         -> reads fine
$ git remote -v         -> works
$ [ -w . ] && echo WRITABLE  -> WRITABLE

100% reproducible, same as reported in #92958.

Second, independent defect (does NOT go away with the rollback)

device_stage_files on the mapped network drive fails in both states —
before and after the rollback — while device_list_dir on the same path
returns a complete listing and device_bash (post-rollback) reads and writes
the same files without trouble:

device_stage_files ["Z:\\projectdata\\notes.md"]
-> Could not stat Z:\projectdata\notes.md

The identical call against a local folder succeeds. This appears to be the
long-standing mapped-drive gap (#41687, #45297, #54069, #66006), not part of
the KB regression. The string Could not stat does not appear in any existing
issue as far as I can tell.

Ruled out during diagnosis

• Token separation / UAC. EnableLinkedConnections was set to 1 and the

machine rebooted. net use from an elevated PowerShell then lists Z:
as OK. device_stage_files still fails. So the mapped-drive invisibility
is not the elevated-token issue — consistent with the mount running under a
service account rather than the interactive user (#44486).

• Folder connection. connectedFolders lists Z:\projectdata correctly;

disconnecting and reconnecting through the folder picker changes nothing.

• UNC as an alternative. device_request_folder_access rejects it

outright: UNC paths are not allowed: \\fileserver\share\projectdata

Suggested takeaway

The Plan9 regression is not ARM64-specific. It is the September 2026
cumulative update across architectures — KB5124012 on ARM64, KB5124008 on x64.

Additional affected configuration: x64 (not ARM64) — same regression via KB5124008

Confirming this is not ARM64-specific. I hit the identical failure on an x86-64 machine right after the September 2026 Patch Tuesday.

Machine / OS

• ASUS Zenbook 15 UM3504DA — AMD Ryzen 7 7735U (x86-64, not ARM)
• Windows 11 Home, version 25H2, OS build 26200.9445
• Windows update installed 2026-09-09 (~10:00 local): KB5124008 ("2026-09 Security Update", 26200.9445) — the x64 24H2/25H2 sibling of KB5124012 (26H1/ARM64) cited in the report; same Patch Tuesday rollup.
• Claude Desktop app: 1.46388.4 — unchanged across the breakage (reinforces the OS-update A/B finding: it's the Windows KB, not the app).

Symptom — identical. device_bash fails at shell init with:

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

The connected folder cannot be reached from the shell, while device_list_dir / device_stage_files / device_commit_files keep working normally — so file access is fine, only the Plan9 share attach for the shell is broken.

Timeline

• 2026-09-07 and 2026-09-08: device_bash worked; the local script ran fine.
• 2026-09-09, after KB5124008 installed: every device_bash call fails with the error above.

Takeaway: the regression is present in the x64 September cumulative (KB5124008) too, not just ARM64/KB5124012 — pointing at the shared servicing stack rather than an ARM-only component. Uninstalling the KB should restore it (not yet attempted on this machine).

<html>
<body>
<!--StartFragment--><html><head></head><body><h1>[BUG] Cowork Windows x64: add_plan9_shares reports success but attaches zero shares — including the app's own SDK share — on Win 11 Pro with Hyper-V installed, after a clean reinstall</h1>
<h2>Summary</h2>
<p>On Windows 11 Pro x64 (MSIX build 1.49585.0.0), the Cowork VM boots cleanly and reaches the API, but <strong>no Plan9 drive shares are attached at all</strong>.</p>
<p>The host-side step reports success with entirely normal timing:</p>
<pre><code>[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed (25ms)
</code></pre>
<p>The guest then reports:</p>
<pre><code>sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
</code></pre>
<p>No HRESULT. No error. No warning on the host side. The failure is silent until the guest tries to use the shares.</p>
<p><strong>The decisive detail:</strong> this is not about which folders the user connects. The application's own SDK share — <code>c</code>, mapping drive C: — is also absent, so <code>postConnect</code> fails on every launch (evidence section 1). <code>add_plan9_shares</code> attaches nothing whatsoever and still reports success.</p>
<p>The workspace shell (<code>device_bash</code>) is completely unusable. File tools (list, stage, commit) work normally, so host-side folder grants themselves are fine.</p>
<h2>What this is NOT — eliminated by direct test</h2>
<p>Please read this before triaging as a duplicate.</p>

Common explanation | Status
-- | --
Windows Home lacking vmms (#27906, #43915, #31991) | Eliminated. Upgraded Home to Pro mid-session. vmms now Running. Behaviour identical.
Hyper-V not installed | Eliminated. Hyper-V, Virtual Machine Platform and Windows Hypervisor Platform all enabled, machine rebooted.
Stale or corrupt VM bundle | Eliminated. Full uninstall and reinstall of Claude Desktop; bundle rebuilt from scratch. Behaviour identical.
Stale config from the Home-edition period | Eliminated. Same clean reinstall, performed after the Pro upgrade.
CoworkVMService not running | Eliminated. Running, StartType Automatic, correct binary path.
Folders connected after VM boot | Eliminated. Folders granted before boot, then service cycled.
OneDrive-synced folders (#25293) | Eliminated. All test folders are plain local paths, not redirected.
MSIX user-profile redirection | Eliminated. A folder outside the profile (C:\COWORK) fails identically.
Spaces in folder names | Eliminated. FFQ (no space) fails identically to Claude Projects.
VM fails to start / rootfs missing (#63633, #56542) | Not applicable. VM starts cleanly in ~5.3s and reaches the API.
Stale cowork-vm-nat HNS network | Eliminated. Removed and HNS restarted; no change.

<h2>Secondary defects observed</h2>
<p><strong>a) <code>add_plan9_shares</code> logs success when it attaches zero shares.</strong> This masks the fault completely. The first actionable signal arrives much later, from the guest, in a different log. Raised in #92958 and reproduced here on x64. The step should fail loudly when the attached share count is zero — especially when the app's own required share is among the missing.</p>
<p><strong>b) <code>CoworkVMService</code> cannot be configured by an administrator.</strong> <code>sc config</code> and <code>sc failure</code> both return access denied from an elevated prompt. The service DACL grants no ACE to <code>BUILTIN\Administrators</code>:</p>
<pre><code>D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-...)
</code></pre>
<p>Matches #88073. The startup type had to be corrected by a direct registry write instead.</p>
<p><strong>c) Log location changed without migration.</strong> Diagnosis was delayed substantially because the app now writes to <code>%LOCALAPPDATA%\Claude\Logs</code> while the old packaged path still holds a plausible-looking but three-week-stale <code>cowork_vm_node.log</code>. Removing or marking the old file would help.</p>
<h2>Related issues</h2>
<ul>
<li><strong>#92958</strong> — same signature (success, zero shares), ARM64, attributed to KB5124012</li>
<li><strong>#72685</strong> — Plan9 share <code>'c'</code> fails, Windows 11 Home AMD, HRESULT 0x8007273f</li>
<li><strong>#63633</strong> — bundlePath resolves to un-virtualised Roaming while data lives in the package container</li>
<li><strong>#56542</strong> — Roaming vs Local path mismatch after update</li>
<li><strong>#88073</strong> — CoworkVMService DACL omits Administrators</li>
<li><strong>#27906</strong> — docs should state the Windows Pro requirement</li>
<li><strong>#43896</strong>, <strong>#43290</strong> — Plan9 share access denied, closed unresolved</li>
</ul>
<h2>Impact</h2>
<p>The workspace shell is entirely unavailable. File read, stage and commit still work, so a session can continue at reduced capability, but nothing can be executed against connected folders in place — no scripts, no builds, no version control. For work that depends on running commands against local files, this is blocking.</p>
<p>Diagnosing it cost a full working day, largely because the failure reports success.</p></body></html><!--EndFragment-->
</body>
</html>

x64 rollback A/B done (sixth machine) — and a direct counter-example to the August-preview hypothesis: this machine ran the 2026‑08 Preview (KB5120998, 26200.9278) for 11 days with the mount working, broke only when KB5124008 landed, and works again on .9278 after rollback

Closing the caveat in my earlier comment. Uninstalled Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26, rebooted, and device_bash works on the first boot with app 1.49585.0.0, SDK 2.1.260 and VM bundle 2a762adf… unchanged. KB5124007 (SSU) and KB5126052 (.NET) left installed — a third machine agreeing that KB5124008 alone is sufficient.

| Windows build | Claude Desktop | device_bash |
|---|---|---|
| 26200.9445 (KB5124008 installed) | 1.49585.0.0 | FAILS — every call; 3 shares (c, d, e) requested, 0 mounted |
| 26200.9278 (KB5124008 removed) | 1.49585.0.0 | WORKS — mounted 3/3, folder read/write verified from the shell |

**1. The August preview is not the trigger — it is the build I rolled back to**

@JGEC2025 raised the possibility that the regression sits in the optional 2026‑08 Preview (KB5120998 → 26200.9278), which the September cumulative then carried forward. This machine is a direct test of that, and it says no:

| Date (local, America/Winnipeg) | Event | Build | Guest log (coworkd\user-<SID>.log) |
|---|---|---|---|
| Aug 29 09:43 | KB5120998 (2026‑08 Preview) installed | 26200.9278 | — |
| Sep 1, 2, 4 (×2), 5, 8 (×2) | Normal use, every VM boot | 26200.9278 | mounted 3/3 Plan9 shares on each boot |
| Sep 9 00:39 | Last successful device_bash | 26200.9278 | — |
| Sep 9 00:45 | KB5124008 installed | 26200.9445 | (mirror stops writing — see §3) |
| Sep 9 00:46 → 01:34 | Four VM boots, all fail | 26200.9445 | — |
| Sep 9 11:19 | KB5124008 removed | 26200.9278 | — |
| Sep 9 11:22, 11:26 | VM boots, device_bash works | 26200.9278 | — |

Sources: Setup event log (KB5120998 Installed 2026‑08‑29 09:43:31; KB5124008 Installed 2026‑09‑09 00:45:18, Absent 11:19:09), WU history (2026-08 Preview Update (KB5120998) (26200.9278)), CBS registry (RollupFix 26100.9278.1.35 currently installed). @HotshotJacko1's rollback also landed on .9278 and works.

So the breaking change is inside the delta between the 9278 preview and the 9445 security release, not anywhere in the August→September span. @JGEC2025's Sep 8 break may simply be a KB5124008 install that finished earlier than its history entry suggests (here the Setup log shows KB5124008 staged/installed 00:01–00:45 while WU history records it at 00:05) — worth checking the Setup event log rather than the Update history page.

2. What that delta touches in the HCS stack

Against @retsudo-star's list of Hyper‑V binaries replaced by the September wave, on this working 9278 machine:

| Binary (System32) | Working 26200.9278 (this machine) | Broken 26200.9445 (@retsudo-star) |
|---|---|---|
| vmcompute.dll | 10.0.26100.9278 | 10.0.26100.9444 |
| computecore.dll | 10.0.26100.9278 | 10.0.26100.9278 |
| vmdevicehost.dll | 10.0.26100.9278 | 10.0.26100.9278 |
| vmwpctrl.dll | 10.0.26100.9278 | 10.0.26100.9278 |
| p9np.dll | 10.0.26100.9278 | 10.0.26100.9278 |
| computestorage.dll / vmbkmcl.sys | 10.0.26100.9278 | (not listed) |
| hvsocket.sys / vhdmp.sys / vmswitch.sys | .8972 / .8875 / .8457 | (not listed) |

p9np.dll, computecore.dll, vmdevicehost.dll and vmwpctrl.dll are the same file versions in a working and a broken state, so they are not the change. Of the user‑mode HCS files listed, only vmcompute.dll (9278 → 9444) differs — and that is the Host Compute Service handling HcsModifyComputeSystem and the Plan9 share plumbing. Caveat: kernel side unverified. If someone still on 9445 can post hvsocket.sys, vmbkmcl.sys, vhdmp.sys and vmswitch.sys versions from System32\drivers, that closes the gap (@Gladdiator notes vmswitch.sys was replaced on their machine). vmwp.exe shows 10.0.26100.1 here vs .8875 there; that looks like a forwarder/RTM stamp and I wouldn't read into it.

3. Host log identical in all three states; guest mirror stopped exactly at the KB

cowork-service.log, three shares per boot, broken boots (00:46, 01:10, 01:22, 01:34) and working post‑rollback boots (11:22, 11:26) alike: Adding Plan9 share via HcsModifyComputeSystem: name=c|d|e … flags=0x10 hasToken=true → HcsModifyComputeSystem returned: hr=0x0 ×3 → Sent plan9Shares notification (3 shares). Same as @yuriyda and @tedwuted-oss, third machine.

Guest mirror C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log: last line is 05:39:23 UTC (00:39 local) — the last successful device_bash before the KB reboot. Nothing from the broken boots, and nothing from the two working post‑rollback boots either. Same pattern as @yuriyda and @tedwuted-oss (mirror dies at the KB event, does not resume after rollback), so the guest‑side EINVAL was never captured here. That mirror defect is what makes this look "silent" to most reporters.

For the OP's item 3: cowork_vm_node.log did not die here, it moved — %APPDATA%\Claude\logs\ (Roaming) stopped 2026‑08‑20, %LOCALAPPDATA%\Claude\Logs\cowork_vm_node.log (Local) is live with every Sep 9 boot including post‑rollback. Matches @adamcharlesgreen-ship-it and likely explains the dead/live split.

Environment: Windows 11 25H2 x64, Claude Desktop 1.49585.0.0 (MSIX), Electron 44.2.0 / Node 24.20.0, WSL2 also installed (its drvfs 9p mounts of C:/D:/E: worked throughout), Defender only. Windows Update paused. Full logs for all three states available.

Same failure on x64, not just ARM64.

Environment
Claude desktop app 1.49585.0 (Electron 44.2.0, Node 24.20.0)
Windows 11 25H2, build 26200.9445, x64
KB5124007 installed 2026-09-08, KB5124008 installed 2026-09-09
(KB5124008 = September 2026 cumulative for 26200.9445)
device_bash worked normally before these updates.

Every device_bash call fails immediately with the same string:

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

No shell starts, so no in-VM diagnostics are possible.

Verified here:

• Not drive-specific. Original connected folder is on a mapped drive (R:).

I granted a second folder on the system drive (C:\Users\...\Links) as a
control — it also fails to mount, same message. Zero shares mount.

• get_device_info lists both folders under connectedFolders, so the app

registers them; the failure is in the share layer.

• device_list_dir / device_stage_files / device_commit_files still work.
• VirtualMachinePlatform: State : Enabled (dism /get-featureinfo).
• Fully quitting and reopening the desktop app does not fix it.
• Adding a new folder does not re-trigger a working mount.

Second symptom, same onset: since the same moment, every new conversation in
a project re-shows the "Folder access request" dialog for the project's
context folder, as if the previous grant never persisted. Both symptoms
started together, which points at one cause in the share/mount layer.

So the regression is not architecture-specific: ARM64 on 28000.2954/KB5124012
and x64 on 26200.9445/KB5124008 both break the same way.

Third machine on 26200.9445 — vmcompute.dll 9444 confirmed, plus the four driver versions @Harskov asked for. Still on the broken build, not rolled back.

Environment

• Windows 11 25H2 x64, build 26200.9445
• KB5124008 (Update history: 2026-09-09; SSU KB5124007 2026-09-08)
• Claude desktop 1.49585.0 (Electron 44.2.0, Node 24.20.0)
• device_bash dead since the update: sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
• No rollback performed — these are broken-state values.

Host Compute Service (matches @Harskov's broken-state values exactly):

C:\Windows\System32\vmcompute.dll   10.0.26100.9444
C:\Windows\System32\vmcompute.exe   10.0.26100.1

Kernel side, System32\drivers — version AND last-write time:

| File | FileVersion | LastWriteTime (local) |
|---|---|---|
| hvsocket.sys | 10.0.26100.8972 | 2026-07-29 06:02:30 |
| vmbkmcl.sys | 10.0.26100.9278 | 2026-08-28 08:03:02 |
| vhdmp.sys | 10.0.26100.8875 | 2026-09-08 21:40:12 |
| vmswitch.sys | 10.0.26100.8457 | 2026-09-08 21:40:14 |

Two things worth flagging:

1. hvsocket.sys and vmbkmcl.sys were NOT touched by this update — their write times predate it by weeks. So the vsock transport binary itself is unchanged on a machine where the Plan9 mount fails.

2. vhdmp.sys and vmswitch.sys WERE rewritten by the update — both at 2026-09-08 21:40, two seconds apart — yet their version resources are OLDER than the build (8875 and 8457). This reconciles @Gladdiator's "vmswitch.sys was replaced (file times 9 Sep 01:46)" with version tables that show no change: for these two files, version diffing gives a false negative. Anyone comparing 9278 vs 9445 by FileVersion alone will conclude they are identical when they are not the same bytes.

Suggestion: for vhdmp.sys and vmswitch.sys, compare by hash rather than by version. If someone who has rolled back to 26200.9278 / 26100.9278 posts Get-FileHash for those two, we can settle whether the kernel side is really out of the picture or whether version stamps have been hiding a change.

Side note on the install date: KB5124008 shows as installed 2026-09-09 in Update history, but these driver write times are 2026-09-08 21:40 local — consistent with @Harskov's point that staging finishes before the history entry, and with @JGEC2025's machine appearing to break "a day early".

[Bug] Cowork local sandbox (device_bash) broken after Desktop auto-update — Plan9 share never mounts

Product: Claude Desktop for Windows (Cowork / remote-devices local sandbox)
Version: 1.49585.0.0 (started failing right after auto-update from 1.46388.x)
OS: Windows 10.0.26200.9445 (Insider), WSL 2.7.13.0, Docker Desktop present

Symptom: The Cowork microVM boots, but the connected folder never mounts in the guest.
device_bash consistently returns:
"sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared"
File transport (stage/commit) still works; only the in-VM shell/mount is broken.

Host log path %APPDATA%\Claude\logs is frozen since the update (last write 2026-08-21);
the current build writes no findable VM logs, so the add_plan9_shares failure isn't visible.

Ruled out (no change): full reinstall, Windows reboot, Restart-Service vmcompute,
enabling HypervisorPlatform (+reboot), renaming vm_bundles/claude-code-vm (bundle refresh),
wsl --shutdown, stopping Cloudflare WARP, closing Docker Desktop, profile folder reset.
Downgrade impossible locally: older WindowsApps payloads (1.46388.x) fail to -Register (0x80073CF9).

Impact: all local-file / device automations that rely on device_bash are down.
Request: fix Plan9/HCS share mounting in the VM launch path, or provide a way to pin/rollback
to the previous working build (1.46388.x).

<html>
<body>
<!--StartFragment--><p dir="ltr"><strong>Confirmed on x64: KB5124008 (the 24H2/25H2 sibling of KB5124012) causes this. A/B verified by uninstall.</strong></p>
<p dir="ltr">This issue is currently scoped to ARM64. It reproduces on <strong>x64</strong>, triggered by the KB released alongside KB5124012 in the same September 2026 Patch Tuesday.</p>
<p dir="ltr">Environment:</p>
<ul dir="ltr">
<li>Windows 11 Pro, x64, OS build 26200 (25H2)</li>
<li>Claude Desktop 1.49585.0 — held constant across the whole test</li>
<li>Electron 44.2.0, Node 24.20.0</li>
<li>Hyper-V <code>vmms</code>: Running</li>
</ul>
<p dir="ltr">Symptom — every <code>device_bash</code> call, including a bare <code>echo hello</code>, exits 1 before the command runs:</p>
<div><div role="group" aria-label="Code" tabindex="0"><div><div></div></div><div><pre style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(20, 24, 31); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;">sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared</code></pre></div></div></div>
<p dir="ltr"><strong>A/B confirmation:</strong></p>
<div dir="ltr">
State | Result
-- | --
Working through 2026-09-08 | ✅
KB5124008 + KB5126052 installed 2026-09-09 | ❌ broken
App restart, full OS reboot | ❌ still broken
KB5124008 uninstalled | ✅ working — both folders mount, read/write/grep/python all fine

</div>
<p dir="ltr">KB5124008 is the September 2026 cumulative for Windows 11 24H2/25H2 (builds 26100.9445 / 26200.9445). KB5124012 is its ARM64 counterpart from the same release.</p>
<p dir="ltr">Ruled out before finding the cause, in case it saves anyone time:</p>
<ul dir="ltr">
<li>Windows Home / missing <code>vmms</code> (#27906) — Pro, <code>vmms</code> running</li>
<li>OneDrive placeholder files (#25293) — a plain <code>C:\Users\&lt;user&gt;\ClaudeTest</code> with no spaces or hyphens failed identically</li>
<li>Spaces/hyphens in path (#31988) — same clean folder failed</li>
<li>WSL — not installed, and irrelevant; Cowork uses Hyper-V</li>
</ul>
<p dir="ltr">The error wording is diagnostic: "<strong>no</strong> Plan9 drive shares mounted", matching this issue's finding that <code>add_plan9_shares</code> reports success while attaching zero shares.</p>
<p dir="ltr">Throughout the outage <code>device_list_dir</code>, <code>device_stage_files</code> and <code>device_commit_files</code> kept working normally — only the in-place shell was affected. Possibly related: Microsoft Q&amp;A reports File History breaking after KB5124008 + KB5126052.</p>
<p dir="ltr"><strong>Please widen this issue beyond ARM64</strong> — it's the servicing change, not the architecture.</p><!--EndFragment-->
</body>
</html>

On Windows 11 x64 (not ARM64), same exact symptom: RPC error -1: failed to mount ... under Plan9 share "c" which is not mounted, reproducible across multiple existing Cowork sessions/agents while newer sessions worked fine. Started right after installing KB5124008 (2026-09 security patch, build 26200.9445) on 2026-09-09. Uninstalling KB5124008 (wusa /uninstall /kb:5124008) + reboot immediately fixed it. Claude Desktop version 1.49585.0. Looks like the same regression family as this issue, just hitting x64 too.

Same failure on x64, not ARM64-only — and the same rollback fixes it.

• Windows 11 Home, build 10.0.26200 (25H2), AMD64. Claude Desktop (Cowork), latest.
• Shell (device_bash) worked 2026-09-08 (last success ~14:00 UTC). Every call from 2026-09-09 failed:

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=1005 gid=1005
-> bash failed on resume, create, and re-resume

• Connected-folder file tools (read/write via the app) kept working; only the in-VM shell was dead. Identical to the report above.
• Replacing the VM bundle under %APPDATA%\Claude\vm_bundles made no difference (three identical failures after the swap).
• Windows updates installed in the window: KB5124007 (Security Update, 2026-09-08), KB5124008 (Security Update, 2026-09-09), KB5126052 (Update, 2026-09-09). KB5124008 is the 2026-09 cumulative for build 26200, i.e. the x64 counterpart of KB5124012.
• Rollback confirms it: uninstalled KB5124008 (Settings → Update history → Uninstall updates), restarted, app version unchanged → device_bash works on the first call (df -h answers, connected folder mounted and listable). Windows Update paused to keep it off.
• Host log: nothing under %APPDATA%\Claude\logs has been written since 2026-08-20, so I could not capture the add_plan9_shares lines for the broken boots; happy to pull them if someone points me at the current log location.

Windows 10 22H2 x64 — same signature, different KB, not covered by the current title

Adding a third branch. I filed #93071 before this issue was broadened; it is now marked duplicate, but Windows 10 is not represented in the current scope (ARM64 28000.2954 / x64 26200.9445). Flagging it here so it does not fall outside the fix.

| | |
| ----------------- | ------------------------------------------------------------ |
| OS | Windows 10 22H2 x64, build 19045.7725 |
| Update | KB5122878, installed 2026-09-08 by NT AUTHORITY\SYSTEM |
| App | 1.49585.0 (also failed on 1.46388.2) |
| Connected folders | 5, all under Dropbox |

Identical guest-side string:

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

and the same secondary failure on the recovery path:

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

Last working 2026-09-04, broken from 2026-09-08 onward. Survives a full app restart and the 1.46388.2 → 1.49585.0 upgrade. device_list_dir, device_stage_files and device_commit_files are unaffected — the failure is isolated to Plan9 share attachment, exactly as reported here.

Evidence quality: correlation only. I have not done an A/B rollback on this machine. The window is one day wide and nothing else changed.

Why rollback is a worse workaround on this branch. KB5122878 remediates CVE-2026-85880 (Windows ALPC Elevation of Privilege, CVSS 7.8), which Microsoft flags as Exploitation Detected in the September 2026 release notes. The MSRC affected-product data lists fixedBuildNumber 10.0.19045.7725 for Windows 10 Version 22H2 x64 under KB5122878 — i.e. exactly this build. Windows 10 is also on ESU, so this is one of the few updates still shipping for it. Uninstalling the September cumulative is therefore a materially worse trade here than on the Windows 11 branches, where the A/B rollback is being used as the practical workaround.

That is the main reason I am adding this branch: for Windows 10 the "just remove the KB" answer is not really available, so a host-side fix or a documented mitigation matters more.

Happy to run the A/B if that is what is blocking confirmation of this branch — it just carries the security cost above.

Same signature on a third platform: x64 Windows 10 22H2 (ESU), build 19045. Claude desktop 1.49585.0.0, Claude Code 2.1.260 — same versions as this report.

[VM:steps] vm_boot completed (675ms)
[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed (25ms)
[VM] Network status: CONNECTED
[VM] API reachability: REACHABLE
...
[vm-stderr oneshot-] sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared

Guest side, from main.log:

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

Two folders were connected at the time; neither mounted.

Trigger here is a different KB. Not KB5124012 — the September rollup for this branch, Package_for_RollupFix~31bf3856ad364e35~amd64~~19041.7725.1.26. It replaced the Host Compute Service binaries:

vmcompute.exe      9/9/2026 6:11:48 AM
vmwp.exe           9/9/2026 6:11:48 AM
computestorage.dll 1/14/2026 5:06:29 AM   (untouched)

Last good run was 09-09 02:25, several hours after those files were replaced at 06:11 — cowork-svc kept the old HCS loaded until it restarted at 23:31 that night, and every call has failed since.

Confirmed fix, with the app version held constant:

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

After a reboot, vmcompute.exe / vmwp.exe reverted to 8/11/2026, all shares mounted on the first call, and the app's own preflight passed. Same A/B result as yours, different branch and different KB.

Two diagnostic notes that cost me most of a day:

• p9rdr.sys / p9np.dll were not modified (Aug 2026 / Jul 2025 respectively). They are the Windows-side 9p client, not the host compute path — checking them first produces a confident and wrong "Windows isn't involved" conclusion. Check vmcompute.exe / vmwp.exe / computestorage.dll instead.
• Get-WindowsPackage -Online package names for cumulative updates contain no KB number, so filtering by KB returns nothing and reads like the update isn't installed. Sort by InstallTime instead. Get-HotFix dates are date-only and timezone-shifted, so they mislead too.

Three branches, three KBs, one signature (this issue: ARM64 Win11 / KB5124012; #92984: x64 Win11 26200 / KB5124008; here: x64 Win10 22H2 / 19041.7725). A fix scoped to the Windows 11 paths would miss Windows 10.

One suggestion: add_plan9_shares returning success in 25ms while attaching nothing means the app proceeds as if mounted, and the user's first symptom is an opaque sandbox-helper error inside an unrelated tool call much later. A post-attach check that the expected shares are actually present in the guest — failing with the missing share names — would turn this into a one-line error instead of a day of guessing.

Following up on my earlier x64/KB5124008 report: worth flagging the same security trade-off @hector751 raised for KB5122878. KB5124008 also ships a fix for an actively exploited vulnerability — CVE-2026-81963 (High, CVSS 7.8, on CISA KEV) — alongside dozens of critical (9.8) CVEs. So "just uninstall the KB" is a real security regression on this branch too, not a free workaround.

Given three independent host-side triggers now reported (KB5124012 on ARM64, KB5124008 on x64/Win11, the HCS rollup package on @bradfordb's branch, KB5122878 on Win10/22H2 ESU) all producing the identical Plan9 share "c" which is not mounted signature, this looks less like "revert this one KB" and more like the Cowork sandbox's Plan9/HCS attach path needs to be hardened against whatever these updates changed in Host Compute Service — a host-side/app fix rather than relying on users to skip security patches indefinitely.

Re-installing KB5124008 on my end for now given the active exploitation status; happy to re-test against any candidate fix.

ARM64 on the 26200 branch — same failure, KB5124008.

The ARM64 reports here are on 28000 / 26H1 with KB5124012, and the KB5124008 reports are x64. This machine is the remaining cell: ARM64 running 25H2 on the 26200 branch.

• Surface Pro 11, Snapdragon X X1E80100 — Windows 11 Home 25H2, OS build 26200.9445
• Claude Desktop 1.49585.0, Electron 44.2.0, Node 24.20.0
• KB5124008 installed 2026-09-09 (confirmed in Update history); failures begin the same day
• sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared on every device_bash call, including a bare echo
• Every connected folder fails to mount, including a plain non-OneDrive folder connected purely as a control — so it is not path- or OneDrive-specific
• device_list_dir / device_stage_files / device_commit_files unaffected
• A full machine reboot after the update changed nothing

So KB5124008 breaks ARM64 as well as x64. Combined with the existing reports, the trigger tracks each branch's September cumulative rather than the architecture.

Not A/B confirmed here — I have not removed the update.

Confirming this on a second ARM64 device, with one data point that rules out an app-side fix.

Environment

• Microsoft Surface, Windows 11 26H1 ARM64
• OS build 28000.2954 (KB5124012, 8 Sep 2026)
• Claude Desktop 1.52386.0 (Electron 44.2.0, Node 24.20.0)
• 4 connected folders, all on local fixed disks

Symptom — identical to the report above. Every device_bash call fails immediately:

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

Earlier sessions also returned Plan9 share "c" is not mounted alongside ensure user: user <generated-name> already exists unexpectedly. device_list_dir, device_stage_files and device_commit_files all keep working — only the VM's filesystem mount is affected.

The new data point: I'm on Claude Desktop 1.52386.0, newer than anything in the table above, and the failure is unchanged. No shipped app version fixes this, so "update the app" can be ruled out for anyone landing here.

Timeline — KB5124012 installed 8 Sep. A scheduled overnight automation that had run reliably for months failed on 9, 10 and 11 Sep, all three times before its first step, with this error.

For anyone finding this issue: Anthropic now has a public incident open at status.claude.com ("Degraded functionality for Claude Cowork on Windows", Identified, 10 Sep 15:54 UTC). It states there is no in-app workaround, that restarting or reinstalling won't help, and that Microsoft has developed a fix and is working to release it. On that basis I'd suggest not uninstalling the KB — it's a September security update — unless you're genuinely blocked.

Seconding the secondary defect: add_plan9_shares logging success while attaching zero shares is what made this expensive to attribute. Three nights of failure produced no host-side error at all.

Same bug on x64, different KB — data below in case it helps confirm the scope.

Host: Windows 11 Pro x64 25H2, build 26200.9445, i5-12400F / 32 GB.
KB: KB5124008 (the x64 sibling of your KB5124012), InstallTime 2026-09-08 21:50:12.
Claude Desktop 1.49585.0.0 — unchanged across the break (verified in cowork-service.log
via Client signature verified: ...Claude_1.49585.0.0_x64... on both the last working and the
first broken boot).
SDK 2.1.260. VM bundle hash 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 — identical to yours.

Break point

2026/09/08 18:31:52  [hyperv] mounted 5/5 Plan9 shares    <- last healthy boot
2026-09-08 21:50:12  KB5124008 installed
2026/09/09 13:49:04  [hyperv] mounted 0/5 Plan9 shares    <- and 0/5 on every boot since

No app update in between, so the Windows build is the only variable here too.

One difference worth noting: on x64 the guest logs an explicit error

Your report describes a silent failure. On x64 the host side is silent in exactly the same
way, but C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log does name the failure:

[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] failed to mount Plan9 share "s": Plan9 mount failed: invalid argument
[hyperv] failed to mount Plan9 share "x": Plan9 mount failed: invalid argument
[hyperv] mounted 0/5 Plan9 shares

So the guest-side mount returns EINVAL for all five shares, while the host reports every
HcsModifyComputeSystem call as hr=0x0 and add_plan9_shares completed (5-6ms). This
supports your point that the host-side step should not log completed when zero shares
attached — the host has no idea the guest rejected them.

Misleading downstream error

Because the shares are missing, sdk_install fails and the user-visible error is about SDK
verification, which sends people chasing the wrong thing (reinstalling the workspace, clearing
claude-code-vm, freeing disk space — none of it relevant):

[VM:steps] sdk_install started
[VM:start] Startup failed: 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
[VM:start] Skipping auto-reinstall (already attempted once)

Two secondary defects around the self-repair path:

• Skipping auto-reinstall (already attempted once) persists across restarts, so the built-in

recovery only ever runs once and then gives up permanently.

• The in-app "reinstall the workspace" action deletes rootfs.vhdx / vmlinuz / initrd

but explicitly preserves the compressed .zst cache, so it re-decompresses the same image
and cannot fix anything image-related. In one run the delete also failed with
rootfs.vhdx locked by running VM (EBUSY), skipping.

(The app has since started showing an accurate banner naming the September 8 update — thank
you, that helps a lot.)

Rollback is NOT available on x64

Step 3 of your repro does not work here — the package is flagged permanent:

DISM /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.9445.1.26
  -> Error: 0x800f0825

Remove-WindowsPackage -Online -PackageName "Package_for_RollupFix~...~26100.9445.1.26"
  -> "Removal of a permanent package is not supported" (COMException)

WinRE → Uninstall latest quality update also fails, and there were no restore points. So on
x64 there is no workaround at all beyond switching the session to cloud execution
(Settings → Cowork → turn off "Only on this computer"), which does work and is currently
the only way to get a shell back.

Given that KB5124008 (x64) and KB5124012 (ARM64) are the same September rollup, this looks
like a single regression affecting both architectures, and x64 users cannot roll back.

Another x64 confirmation, matching the many already here — adding since it was requested.

Lenovo laptop, Windows 11 Pro x64, build 26200.9445 after KB5124008 (installed 9/9/2026). Claude Desktop 1.52386.0. Same signature as everyone else: device_bash hanging/failing to start, host side reporting success while nothing actually mounted.

Uninstalled KB5124008 via Settings → Windows Update → Update history → Uninstall updates, rebooted — device_bash came back immediately on the first call, connected folder mounted and listable.

No new information beyond what @yuriyda, @JonathanReams, @avincentx, and others already established, just one more data point on the same fix.

x64 confirmation + completed rollback A/B and working DISM removal steps posted on #92984.

Uninstalled KB5124008 via Settings → Windows Update → Update history → Uninstall updates, rebooted — device_bash came back immediately on the first call, connected folder mounted and listable.

Same issue did like three times. But the device_bash comes up again and iam unable to connect.