[BUG] device_bash / Cowork local device bridge fails on Windows 10 (10.0.19045) — same symptom as #94266/#92958, but NOT Windows 11

Status Open
Maintainer reply None cached
Activity 3 comments · opened Sep 16, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Cowork's local device bridge (device_bash) fails consistently on a Windows 10 Pro machine, reporting the identical error message used for the known Windows-11 "September 8 update" issue (#94266, #92958) — but this machine is Windows 10 Pro, build 10.0.19045 (22H2), not Windows 11. Either the same underlying bug also affects Windows 10, or the error message is misattributing an unrelated Windows 10 failure to that specific Windows 11 incident.

device_list_dir, device_stage_files, and device_commit_files all work fine against the same connected folder — only device_bash (shell/command execution) fails.

What Should Happen?

device_bash should be able to run shell commands (e.g. git) on this machine the same way it can via device_list_dir etc., or if Windows 10 is genuinely unsupported/out of scope for the fix, the error message should say so instead of citing a Windows-11-specific update that this OS will never receive.

Error Messages/Logs

Two error variants seen on the same machine, both containing the line: "A Windows update released September 8 prevents Claude's workspace from reaching your files. We're tracking this issue. Claude Code is unaffected."

1) sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared
   [Note: mnt/<folder> failed to mount and cannot be reached from this shell. Those connected folders are still reachable via device_list_dir / device_stage_files / device_commit_files, by their paths on this device.]

2) Workspace unavailable. The isolated Linux environment on this device failed to start. Use device_stage_files / device_commit_files instead.

Steps to Reproduce

  1. On a Windows 10 Pro (build 19045) machine, open a Cowork session with a folder connected via the device bridge.
  2. Call device_bash with any command (e.g. echo test).
  3. Observe the error above, attributing the failure to a Windows-11-specific September 8 update that does not apply to this OS version.
  4. device_list_dir / device_stage_files / device_commit_files against the same folder succeed normally.
  5. Restarting the Claude desktop app: no change. Full OS reboot: briefly reports "Workspace still downloading," then reverts to the same failure.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.52386.6

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Device: HP ProBook 640 G2, DESKTOP-8V*****. This is a Claude Cowork desktop session (not the Claude Code CLI, and not a direct Anthropic API integration — selected "Other" for Platform and "Other" for Terminal/Shell since neither list covers the Cowork desktop app).

Anthropic's Cowork changelog documents this class of failure as fixed by Microsoft's KB5129195, but that patch targets Windows 11 24H2/25H2 only — it has no Windows 10 equivalent, so this machine can't be "fixed" by that update. Flagging this as a distinct data point from #94266/#92958, both of which are Windows 11 Pro build 10.0.26100.

Happy to provide further logs or a live repro session if useful.

View original on GitHub ↗

3 Comments

clintonabrooks · 29 days ago

Local forensics (Windows 10 Pro 22H2, build 19045.7725)
The UI string about a “Windows update released September 8” is a remapped surface error. On this machine the underlying failure is Plan9 mounting of host drive C: into Cowork’s Linux VM — not a total VM boot failure.

Evidence from %LOCALAPPDATA%\Claude\Logs\cowork_vm_node.log:

Last clean startup: 2026-09-08 14:46 — add_plan9_shares completed, then Startup complete.
Windows 10 Patch Tuesday the next day (2026-09-09) installed:
KB5126421
KB5122878
KB5122877
KB5127070
First bash failure: 2026-09-10 11:59 — Plan9 share "c" which is not mounted (VM had reported Startup complete moments earlier).
Hard fail from 2026-09-10 18:54:
RPC error -1: host drive share "c" not mounted: Plan9 mount failed: invalid argument
Claude then: Skipping auto-reinstall (host drive share "c" did not mount in the guest), leaving VM offline.
After Claude desktop 2.110.0 + refreshed VM bundle today, same class, clearer wording:
add_plan9_shares failed: guest refused share c from the Windows share server: errno=22 (mount)
host drive share "c" not mounted: guest refused share c from the Windows share server: errno=22 (mount)
What still works on the same path: VM boots; guest network CONNECTED; API REACHABLE. device_list_dir / device_stage_files / device_commit_files succeed. Only device_bash (needs Plan9/virtiofs of C:) fails.

Ruled out here: disk space (~97 GB free on C:); missing app/cowork-svc (both running); stale VM image alone (bundle re-promoted today to 88251839…, same refuse).

Takeaway vs Win11-only narrative: this looks like the same Plan9 host-share regression class as #94266 / #92958, but it also hits Windows 10 after the Sept Patch Tuesday packages above. Microsoft’s documented fix KB5129195 is Win11 24H2/25H2-only and is not present on this machine — so Win10 users cannot clear this by installing that KB.

Happy to attach fuller log excerpts if useful.

m3csl3-83 · 5 days ago

Attaching the full cowork_vm_node.log from this machine (2026-08-21 to
2026-10-10). It covers both the working period on the 1.x app generation and
every failing start since, so the before/after transition is visible in one
file. Windows 10 Pro 22H2, build 19045.7725.

github-kommentar-94868.md

cowork_vm_node.txt

m3csl3-83 · 5 days ago

Fixed with KB5129236

github-kommentar-94868-final.md