Repository navigation
[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 #92958
Description
Preflight Checklist
- I have searched existing issues and this hasn't been reported yet
- This is a single bug report (please file separate reports for different bugs)
- I am using the latest version of Claude Code
What's Wrong?
On Windows 11 ARM64, installing the 2026-09 cumulative update KB5124012 (build 28000.2804 -> 28000.2954) breaks the Cowork sandbox VM. add_plan9_shares logs completed with no error, but no Plan9 share is actually attached, so device_bash never starts — even echo alive returns nothing.
Uninstalling KB5124012 restores it immediately, with the Claude Desktop version held constant. This is not an app regression; I first suspected the 1.46388.4.0 -> 1.49585.0.0 app update and was wrong.
Controlled result (app version constant at 1.49585.0.0)
| Windows build | Claude Desktop | device_bash |
|---|---|---|
| 28000.2954 (KB5124012 installed) | 1.49585.0.0 | FAILS — 15/15 calls |
| 28000.2804 (KB5124012 removed) | 1.49585.0.0 | WORKS |
| 28000.2804 | 1.46388.4.0 | WORKS — 15/15 calls (historical) |
Rows 1 and 2 differ only in the Windows build.
Verification after rollback:
mount: /sessions/<id>/mnt/<folder> type fuse (rw,nosuid,nodev,relatime,...)
write: test file written and read back OK
files: 171 files visible in the connected folder
python: 3.10.12 available in the guest
The VM bundle hash is 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 before and after the app update — verified in log, so the guest image is provably not the variable.
What Should Happen?
device_bash should execute in the sandbox VM with the connected folder mounted at $HOME/mnt/<folder>.
Separately, and regardless of the root cause: add_plan9_shares should not log completed when it attached zero shares. The current behaviour turns a host-side failure into a silent one — the only error surfaces later, inside the guest, with no actionable cause. A user has no way to reach the VM to diagnose it, because the shell itself is what is broken.
Error Messages/Logs
Every VM boot on `28000.2954` logs the share step as successful:
[VM:steps] vm_boot completed (61-141ms)
[VM:steps] add_plan9_shares started
[VM:steps] add_plan9_shares completed (4-12ms) <-- reports SUCCESS, no error
[VM] Network status: CONNECTED
[VM] API reachability: REACHABLE
The guest then fails:
RPC error -1: failed to mount
/mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Local/Packages/
Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent/.../uploads
as uploads: source path ... is under Plan9 share "c" which is not mounted
sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
Secondary defect — the recovery path also fails:
create: RPC error -1: ensure user: user <session-name> already exists
unexpectedly: uid=1926 gid=1926
Net result: `bash failed on resume, create, and re-resume`. The shell never starts, so no in-VM diagnostics are possible.
Note: the 4-12ms duration is **not** diagnostic. Historical healthy boots completed in 0-9ms (0, 0, 0, 3, 8, 3, 2, 9, 4, 0, 5, 8, 4, 4, 5, 8 ms across 2026-08-21 .. 2026-09-05), so this step never performed the attach synchronously.Steps to Reproduce
- Windows 11 ARM64 build
28000.2804, Claude Desktop1.49585.0.0, a folder connected to a Cowork session ->device_bashworks. - Install KB5124012 (build becomes
28000.2954), reboot ->device_bashfails; see logs below. - Remove the RollupFix package for
28000.2954(Remove-WindowsPackage -Online), reboot ->device_bashworks again.
Steps 2 and 3 were both performed on this machine. 100% reproducible in both directions.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Windows build 28000.2804. The Claude Desktop version is unchanged (1.49585.0.0) and still works once the Windows update is removed.
Claude Code Version
2.1.260 (installed into the VM by the desktop app; log line [postConnect] Installing SDK: ... version=2.1.260)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
2026-09-05 12:46:30 last VM boot that later served working bash calls
(no VM boots at all between this and 09-09 01:48)
2026-09-09 01:00-01:09 15 bash calls on that VM, ALL SUCCEED
2026-09-09 01:44:34 [VM:shutdown] App quit, stopping VM
2026-09-09 01:47:24 KB5124012 -> "Installed state" (Windows Setup log)
2026-09-09 01:48:48 VM boot, app still 1.46388.4.0, no bash calls made
2026-09-09 03:10:18 VM boot, app now 1.49585.0.0
2026-09-09 06:34:20-08:04:22 15 bash calls, ALL FAIL
2026-09-09 (after removing KB5124012 + reboot) bash WORKS again on 1.49585.0.0
Host prerequisites verified healthy throughout (ruled out)
VirtualizationFirmwareEnabled: True, SLATTrue- VBS
Running;hypervisorlaunchtype: Auto VirtualMachinePlatform: Enabledvmcomputeservice Running;vmmemandvmwp.exealive- VM reported
Network status: CONNECTEDandAPI reachability: REACHABLEon every broken boot - Hyper-V role and WSL are
Disabledwith no distros — neither is required; the utility VM boots regardless
What still works while broken
device_list_dir / device_stage_files / device_commit_files are unaffected. Folder grants persist across reboots. Only the in-VM shell is dead.
NOT A DUPLICATE OF
Checked #72685, #43070, #43290, #43482, #43896, #32828, #25096, #25235, #25293, #25419, #46516, #49997. All of those fail with an explicit error at or before add_plan9_shares — HRESULT 0x8007273f / 0x80310000 / 0x80070005 / 0x800703ed, duplicate share in HCS config, unmount invalid argument, VM connection timeout, or HCS_E_HYPERV_NOT_INSTALLED.
This report is different:
add_plan9_sharesreportscompletedwith no error at all- the VM boots successfully and reports
API reachability: REACHABLE - the missing share is only discovered inside the guest
It is a silent failure, and it is reproducibly caused by a specific Windows update.
Precedent for KB-caused breakage on this platform: #18237 (KB5074109, Windows 11 ARM).
Activity
yuriyda commentedon Sep 9, 2026
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
Claude_1.49585.0.0_x64__pzs8sxrjxfjjc), SDK 2.1.260, VM bundle2a762adfc2eea13eca0d113a2e6452ff00ae3f62Symptom — differs from OP because the first consumer of the missing share here is the SDK install, not
device_bash:Host side is intact:
claude-code-vm/2.1.260/containsclaude(214,687,216 bytes),.payloadand.verified;sha256(claude)matches the hash in.payload.Guest side —
C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log, every VM boot after the update:So on x64 the guest's mount of share
cfails explicitly with EINVAL rather than silently attaching nothing; the net result is the same — 0/1 shares, nothing under/mnt/.virtiofs-root/shared/cis visible, and the.verifiedcheck is simply the first thing to trip over it.cowork-service.logshows 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/initrdrecreated), deleting and re-downloadingclaude-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.
Harskov commentedon Sep 9, 2026
x64 data point: same silent
add_plan9_sharesfailure on Windows 11 25H2 x64, triggered by KB5124008 (26200.9445)Adding an x64 confirmation, since the issue notes x64 status is unknown.
Environment
2a762adfc2eea13eca0d113a2e6452ff00ae3f62— unchanged across working and broken bootsSymptom — identical to the ARM64 report.
add_plan9_shareslogscompletedwith no error, but everydevice_bashcall fails before the shell runs:device_list_dir/device_stage_files/device_commit_fileson the same connected folders keep working — only the shell-side mount is gone.Timeline (from the Setup event log and
cowork_vm_node.log)device_bash(mounts=Subtitle Editor v2:rw, no warning)add_plan9_shares completed (11ms)no Plan9 drive shares mounted— every call since failsThe 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
C:andD:fail in the same callCaveat: I have not done the rollback A/B on this machine, so this is a timeline bisect, not a confirmed cause.
samtuominen commentedon Sep 9, 2026
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.
yuriyda commentedon Sep 9, 2026
@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>.logshows the guest's own mount attempt failing (mounting Plan9 share "c" via vsock port 9902→Plan9 mount failed: invalid argument), beforesandbox-helperreports no shares. That log may be worth checking on your side too.JonathanReams commentedon Sep 9, 2026
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 mountedfailure 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:
So the variable common to both reports is the September release itself, not the architecture.
Environment
device_bashwas in daily use up to 2026-09-08Symptom
Identical string to the original report:
Every
device_bashcall fails at startup, including a bareecho. 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_filesreturned success while subsequentdevice_stage_filesread-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
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
avincentx commentedon Sep 9, 2026
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.
JonathanReams commentedon Sep 9, 2026
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.
MS-UVEC commentedon Sep 9, 2026
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 mountedonoutputs/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:
Every boot after the KB reboot (86 of 86 so far) stops here and never reaches
mounting Plan9 share: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.vhdxon the host has no read-only attribute and theNT VIRTUAL MACHINE\<id>SID has Full Control, so the RO flag is being applied at the virtual SCSI attach, not the file. @yuriyda'sPlan9 mount failed: invalid argumentand myRead-only file systemon 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:coworkdgoes 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.Startup complete/API reachability: REACHABLE), so from the app's side the VM looks up; onlydevice_bashfails.Also seen during the day: one
CoworkVMServicecrash (SCM 7034 "The Claude service terminated unexpectedly"), twoVM connection timeout after 60 secondswithlast completed step: add_plan9_shares, each followed by an auto-reinstall of the bundle, and twoclaude.exeMoAppHang events.2. Uninstalling KB5124008 is not possible on this machine
wusa /uninstall /kb:5124008→0x800f0825DISM /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-Capabilityfor that capability →1168 Element not found(not in FOD metadata);DISM /Remove-Packageon its wrapper package →Only package owners can remove package (0x80070005).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.
alexch-urb commentedon Sep 9, 2026
Same failure on x64 / Windows 11 25H2 (build 26200.9445, KB5124008) — not ARM64-only
Confirming this reproduces on the mainstream x64 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.
Environment
Error
Identical in shape to the original report — same guest-side origin, same message:
Timeline
add_plan9_sharesentry incowork_vm_node.log; local sessions working normallyHost side is fully healthy — this is the notable part
Everything on the host reports success. There is no error anywhere to act on:
VirtualMachinePlatform— EnabledHypervisorPlatform— Enabledvmcompute— Running (StartType Manual). Full Hyper-V role not installed;vmmsabsent, which is expected for this configuration.Microsoft-Windows-Hyper-V-Compute-Admin, last 48 h: 5 events, all Event ID 1001, all Information — "The Host Compute Service started successfully." 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).vm_bundles\claudevm.bundle\rootfs.vhdxmtime is current, so the VM disk is attached and the guest boots — consistent with the error originating inside the guest.This corroborates the central claim of this issue: the share attachment fails silently, with no HRESULT and no host-side event. HCS itself considers the launch successful.
Additional finding: this is not limited to local-agent-mode
The same breakage also kills
device_bashin cloud sessions linked to this machine. Connecting a folder to a cloud session succeeds, anddevice_list_dir/device_stage_files/device_commit_filesall work normally — those go through the desktop app's host-side file API. But any shell command on the device fails immediately: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.
Useful as a low-friction reproducer — no local session needed, just a connected folder and one
device_bashcall.Ruled out
CldFltis loaded (3 instances) but the failing path is under packagedAppData\Local, not a synced folderfltmc filtersshows onlyWdFilter(Defender). No third-party EDR/AV minifilter. Full stack:bindflt,UCPD,LnvMSRIO,WdFilter,storqosflt,wcifs(0 inst.),CldFlt,bfs,FileCrypt(0 inst.),luafv,UnionFS(0 inst.),npsvctrig,Wof,FileInfoOne correction to the original report
The
add_plan9_sharesduration 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 known-working sessions range 0–21 ms, 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.Open question — where does 1.49585.0 write VM logs?
...\LocalCache\Roaming\Claude\logs\cowork_vm_node.loghas no entries after 2026-08-19 (file mtime 2026-08-24), so today's five failed attempts left no trace in it. A recursive scan ofLocalCachefor files modified in the last 48 h returns Chromium/Electron state,sentry\session.json,sentry\scope_v3.json,config.jsonandrootfs.vhdx— but no log file.So I cannot supply the
add_plan9_shares started/completedpair for a failing run, which would be the direct confirmation that it reports success with zero shares attached. 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. (Sentry state was updated during the failures, so telemetry for these runs likely reached you already.)Not attempted: KB removal
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.
Impact
Local-mode sessions are completely unusable. Cloud sessions still run, and file access to connected folders still works through the host-side API, but
device_bashis 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.Request
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.
SpaceGrayMan commentedon Sep 9, 2026
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
ProductNamestillsays "Windows 10 Pro" — known cosmetic artifact)
.wslconfig: onlymemory=8GB,swap=2GB,guiApplications=falsedocker-desktop(Stopped).vmcompute,vmmem,wslserviceall running.Symptom — identical string, on every
device_bashcall, 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
connected folder via
device_bash).same September wave.
Ruled out
Healthy). I created an empty
C:\claude-test, connected it as a secondfolder, and the failure note then listed both folders as failed to mount —
zero shares attached, not a per-volume problem.
wsl --shutdown(confirmedvmmemgone) +relaunch → identical failure on the very first call.
(
device_list_dir/device_stage_files/device_commit_files) worksperfectly 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.
yuriyda commentedon Sep 9, 2026
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:Guest,
C:\ProgramData\Claude\Logs\coworkd\user-<SID>.log, the 07:39 boot (04:39 UTC), in order: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 readsPlan9 share added: c -> C:\ (port=9902, readOnly=false)instead ofalready 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-binand the session disk attached and mounted normally, and only the 9p-over-vsock mount failed. Your read-only/dev/sdcmay 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.logandmain.logstopped being written after the August app update on my machine too (last entries 2026-08-21). The live files are underC:\ProgramData\Claude\Logs\:coworkd\user-<SID>.logis the guest daemon's log mirrored to the host (UTC timestamps; it has themounting Plan9 share/mounted N/M Plan9 shareslines), andcowork-service.logis the host service (local time). Three caveats: the service log is huge because of per-second polling; the mtime shown by Explorer/Get-ChildItemis 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.35 remaining items
aloknawani commentedon Sep 11, 2026
Confirming this on a second ARM64 device, with one data point that rules out an app-side fix.
Environment
Symptom — identical to the report above. Every
device_bashcall fails immediately:Earlier sessions also returned
Plan9 share "c" is not mountedalongsideensure user: user <generated-name> already exists unexpectedly.device_list_dir,device_stage_filesanddevice_commit_filesall 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_shareslogging success while attaching zero shares is what made this expensive to attribute. Three nights of failure produced no host-side error at all.LafoytaTRM commentedon Sep 11, 2026
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.logvia
Client signature verified: ...Claude_1.49585.0.0_x64...on both the last working and thefirst broken boot).
SDK 2.1.260. VM bundle hash 2a762adfc2eea13eca0d113a2e6452ff00ae3f62 — identical to yours.
Break point
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>.logdoes name the failure:So the guest-side mount returns EINVAL for all five shares, while the host reports every
HcsModifyComputeSystemcall ashr=0x0andadd_plan9_shares completed (5-6ms). Thissupports your point that the host-side step should not log
completedwhen zero sharesattached — the host has no idea the guest rejected them.
Misleading downstream error
Because the shares are missing,
sdk_installfails and the user-visible error is about SDKverification, which sends people chasing the wrong thing (reinstalling the workspace, clearing
claude-code-vm, freeing disk space — none of it relevant):Two secondary defects around the self-repair path:
Skipping auto-reinstall (already attempted once)persists across restarts, so the built-inrecovery only ever runs once and then gives up permanently.
rootfs.vhdx/vmlinuz/initrdbut explicitly preserves the compressed
.zstcache, so it re-decompresses the same imageand 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:
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.
Rossb907 commentedon Sep 11, 2026
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.
drprofesq25 commentedon Sep 11, 2026
x64 confirmation + completed rollback A/B and working DISM removal steps posted on #92984.
azmat007 commentedon Sep 12, 2026
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.
ShymonT commentedon Sep 14, 2026
Same failure here, and I want to add a usage-impact data point rather than
just a +1.
Environment
which is not mounted
EoP vulnerabilities, so uninstalling it is not an acceptable trade on my
work machine.
Impact
I am not a developer using Cowork occasionally. I run my whole personal and
professional knowledge system on it
All of it is built on Python and shell steps in the sandbox. Since 8 September
every one of those runs has to be re-executed by hand through the Windows file
tools, which works but is slower, and any step that genuinely needs Python
(image optimisation, .eml generation, zip packaging) simply cannot run.
That is six consecutive days with no maintainer response on any of the five
open issues covering this. What I am asking for is not a fix date, it is an
acknowledgement: confirm the issue is reproduced, say whether the fix will be
host-side in the app or whether you are waiting on Microsoft, and surface the
real "Plan9 mount failed: invalid argument" error in the UI instead of the
generic "Workspace still starting". Right now users cannot tell a broken
mount from a slow boot.
Happy to provide full logs, DXDiag, or to test a pre-release build.
jackmoxley commentedon Sep 14, 2026
They have acknowledged it, there is a message on the app, and on their status page. Apparently a fix exists, and it's just waiting for Microsoft to deploy.
Although personally I find that a little lazy, a different approach to using microslops borked tooling might be a better approach.
psychjustus commentedon Sep 14, 2026
Confirming this on another machine.
Environment
Symptom: the workspace Linux VM starts, but no host folders mount inside the guest over Plan9. Every workspace bash call fails immediately. The file tools (Read/Write/Edit) and the MCP connectors still work, so it is specifically the host→guest share that is broken.
Representative error (paths/user redacted):
In-app banner: "A Windows update released September 8 prevents Claude's workspace from reaching your files. We're tracking this issue. Claude Code is unaffected."
Impact: file reads/writes and connectors work, so most Cowork tasks still run. What breaks is anything that needs the shell — in my case a nightly scheduled task that pages large data through jq/bash, plus reaching folders outside the mounted roots. Now 5+ consecutive nightly runs affected since ~Sept 8. Restart and reinstall do not help, consistent with the root cause being the Windows update rather than the app.
mpavey commentedon Sep 14, 2026
Microsoft has identified issues that affect some devices after installing the September 2026 Windows security update, released September 8, 2026. On affected devices, host folder shares might be unavailable in Hyper-V-based Linux virtual machines, Remote Desktop Services might stop responding, which can prevent new sessions from being created and can prevent local and remote sign-in, and some USB Audio Class 1.0 devices might fail in multichannel audio modes.
An out-of-band (OOB) update was released today, September 14, 2026, to address these issues. For most versions of Windows, these are cumulative updates that include all improvements from the September 2026 Windows security update released September 8, 2026, so you do not need to install any previous update first, except as noted below for hotpatch updates.
For Windows 11, versions 26H1, 25H2, and 24H2, this OOB update is a security update. It downloads and installs automatically from Windows Update and from Windows Update for Business in accordance with configured policies. It is also available from the Microsoft Update Catalog and syncs automatically with Windows Server Update Services (WSUS).
A corresponding hotpatch update is available from Windows Update for Windows 11, versions 25H2 and 24H2 for devices enrolled in hotpatch updates. Devices must have the September 2026 security update installed to receive this hotpatch update automatically.
The update for Windows 11, versions 26H1, 25H2, and 24H2 includes a security fix to address CVE-2026-62721. The update for Windows 11, version 26H1 also includes a security fix to address CVE-2026-85921.
For Windows 11, version 23H2, and Windows 10, version 22H2 (ESU), this update is an optional non-security update. To install it, go to Settings > Windows Update, select Check for updates, and then select Download and install. It is also available from the Microsoft Update Catalog.
For complete guidance and installation instructions, see the relevant KB articles:
• Windows 11, version 26H1: KB5129194
• Windows 11, versions 25H2 and 24H2: KB5129195
• Windows 11, versions 25H2 and 24H2 (hotpatch): KB5129241
• Windows 11, version 23H2: KB5129242
• Windows Server 2025: KB5129235
• Windows Server 2022: KB5129237
• Windows 10, version 22H2 and Windows 10 Enterprise LTSC 2021: KB5129236
• Windows 10 Enterprise LTSC 2019 and Windows Server 2019: KB5129238
• Windows 10 Enterprise LTSB 2016 and Windows Server 2016: KB5129239
• Windows Server 2012 R2: KB5129243
• Windows Server 2012: KB5129244
JB-Projects-Collabs commentedon Sep 15, 2026
Same issue here on x64. Windows 11, build 26200.9445, KB5124008 installed Sept 11. Claude Desktop [version 1.52386.6].
VM boots (CoworkVMService running), but any local session fails with: RPC error -1: failed to mount /mnt/.virtiofs-root/shared/c/Users/xxx/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/a9ae2acc-3617-47fb-aeea-03129163c75e/1b41582c-c697-45e7-b2e1-8c87e03f3a6e/local_3b42a39d-ed8a-4255-8644-7ff9e4c21c3c/.claude as .claude: source path /mnt/.virtiofs-root/shared/c/Users/xxx/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/a9ae2acc-3617-47fb-aeea-03129163c75e/1b41582c-c697-45e7-b2e1-8c87e03f3a6e/local_3b42a39d-ed8a-4255-8644-7ff9e4c21c3c/.claude is under Plan9 share "c" which is not mounted.
Reboots, service restart and app reinstall don't help.
Shaerif commentedon Sep 20, 2026
Same failure here, different build than what's already listed.
Windows 10 Home Single Language, OS build 10.0.26300.9539 (registry lists DisplayVersion as 26H2, for whatever that's worth). Claude desktop 2.2553.1. Latest cumulative update installed 2026-09-12, KB5124010.
The coworkd log shows the same signature as everyone else:
Same result for both shares, every time, even after a mid-session remount attempt. device_bash is dead. File-level tools (list, stage, commit) still work, so it's isolated to the shell mount path like the other reports here.
Haven't pulled the KB yet since I'd rather not lose the security patch if there's another way around it. I switched from device_bash to desktop-commander and that worked as a workaround. It skips the Plan9 mount entirely, so shell commands still go through fine. For now I'm doing the actual shell work that way instead of Cowork's bash tool, which keeps things moving.
I'm adding this in case the exact KB number helps narrow things down. Can pull more from the log if it's useful.
gestionunvinilo commentedon Sep 20, 2026
Update: Windows 11 got an OOB fix on Sept 14 — Windows 10 (KB5122878, same setup as @hector751's report above) still unconfirmed
Microsoft shipped an out-of-band fix on 2026-09-14: KB5129195 (Win11 24H2/25H2) and KB5129194 (Win11 26H1). The official release notes explicitly name the root cause: "Some applications that use HCS-managed virtual machines experienced issues when sharing host folder with Linux VMs using Plan9." Anthropic's status page also marks the Cowork-on-Windows incident as resolved, citing this patch.
However, this appears to be Windows 11-only. The Windows 10 equivalent released the same day, KB5129236 (21H2/22H2, build 19045.7727), does not mention Plan9/HCS in its own release notes — only RDS instability. I'm still on KB5122878 (same as @hector751 above) and haven't installed KB5129236 yet.
Can anyone on Windows 10 confirm whether KB5129236 actually fixes device_bash, or whether Windows 10 still needs a separate patch? Would help to know before this issue gets assumed closed now that Windows 11 is fixed.
samdrake113 commentedon Sep 23, 2026
Windows Insider Release Preview (26H2) is still affected, and the GA fix can't be applied.
Build 26300.9539, Release Preview channel (KB5124010 flight, 10 Sep); LCU Package_for_RollupFix
31bf3856ad364e35amd64~~26100.9539.1.19 installed 2026-09-22 20:4726H2 enablement package KB5121794 installed; x64
Same signature: VM starts, Plan9 shares don't mount, shell fails
The GA fix KB5129195 (26300.9457) is a lower build than 9539, so it isn't offered
The 22 Sep preview KB5124010 (26300.9550) from the Update Catalog returns "The update is not applicable to your computer"
AllowOptionalContent = 3 and "Get the latest updates as soon as they're available" are both on; no newer RP build is offered
No earlier cumulative update is installed to roll back to (only 26100.1742 staged)
Release Preview devices have no route to the 14 Sep fix until the next RP flight. It would help if the known-issue note mentioned Insider channels.
chrisgali01 commentedon Sep 24, 2026
Additional data point: Windows Server 2022 is affected too.
device_bash unusable; device_list_dir / device_stage_files / device_commit_files still work
philpav commentedon Sep 24, 2026
I just installed KB5129236 on Windows 10 and the error is gone.