[BUG] Cowork Windows 10 22H2 x64: `sandbox-helper: no Plan9 drive shares mounted` — device_bash dead since 2026-09-08, survives app restart and app update

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?

Every device_bash call from a Cowork session on this machine fails immediately,
including echo ok - a command that needs no mounted folder at all:

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

The sandbox VM's shell never starts, so nothing can be run on the computer any
more: no scripts, no in-place file edits, no renames or moves.

The rest of the device bridge is healthy - get_device_info, device_list_dir,
device_stage_files and device_commit_files all still work normally. The failure
is isolated to attaching the Plan9 shares to the guest VM.

This worked fine on 2026-09-04 and broke on 2026-09-08, the day Windows 10
cumulative update KB5122878 (OS build 19045.7725) installed itself. It survives
a full app restart and an app version upgrade (1.46388.2 -> 1.49585.0), so the
change came from the host OS, not from the app.

Same error string as #92958, but that report is Windows 11 ARM64 with a
different KB (KB5124012). This is Windows 10 22H2 x64.

What Should Happen?

device_bash should start and run commands as it did until 2026-09-04: the
connected folders mounted under $HOME/mnt/, and plain commands like echo ok
succeeding regardless of mount state.

At minimum, if the host cannot attach the Plan9 shares, the failure should be
reported where it actually happens - host-side share attachment returned zero
shares - instead of only as a guest-side mount error that gives no hint that a
Windows update is involved.

Error Messages/Logs

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

[Note: mnt/Email processing, mnt/_Inbox, mnt/HRC, mnt/RenDit, mnt/Claude skills
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.]

Steps to Reproduce

1. On Windows 10 22H2 x64 with KB5122878 installed (OS build 19045.7725),

open the Claude desktop app and start a Cowork task.

1. Connect one or more local folders to that task. In my case five folders

under C:\Users\<user>\Dropbox\ — the specific folders do not matter.

1. Ask Claude to run a shell command on the computer, e.g.

"run echo ok on my computer". This invokes the device_bash tool.

1. Every device_bash call fails immediately with the error below — including

echo ok, which needs no mounted folder at all. The shell never starts,
so this is not a per-command or per-path failure.

1. Confirm the rest of the device bridge is unaffected: ask Claude to list one

of the connected folders (device_list_dir). That succeeds and returns the
folder contents normally. device_stage_files and device_commit_files also
still work.

1. Fully quit the desktop app and relaunch it, then repeat step 3.

Identical failure.

Regression window: device_bash ran dozens of commands successfully against
all five folders on 2026-09-04 (ls, cp, mv, md5sum, python3 scripts, no
errors). It was broken on 2026-09-08 and has stayed broken since. KB5122878
installed itself on 2026-09-08. Nothing else changed on the machine.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.49585.0 (Claude desktop app / Cowork — Claude Code CLI not installed; also failed on 1.46388.2)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Why "Last Working Version" is misleading here

This is a regression, but not an app-version regression. The same app build
that worked on 2026-09-04 (1.46388.2) was failing on 2026-09-08. The app has
since auto-updated to 1.49585.0 and the failure is byte-identical. So please
do not bisect on app versions — the change came from the host OS.

Environment

| | |
|---|---|
| Platform | win32 |
| Arch | x64 |
| OS | Windows 10 22H2, build 19045.7725 |
| KB5122878 | installed 2026-09-08 by NT AUTHORITY\SYSTEM (automatic Windows Update) |
| Claude desktop app | 1.49585.0 (also failed on 1.46388.2) |
| Electron | 44.2.0 |
| Node | 24.20.0 |
| Connected folders | 5, all under C:\Users\<user>\Dropbox\ (Dropbox-synced, and working fine until 2026-09-08) |

Verified on the machine (PowerShell):

OS: 10.0.19045.7725

HotFixID Description InstalledBy InstalledOn
-------- ----------- ----------- -----------
KB5122878 Security Update NT AUTHORITY\SYSTEM 8-9-2026 00:00:00

The same query also asked for KB5124012 and returned nothing: that KB is NOT
installed here — it targets Windows 11 (build 28000.x) and does not apply to
this machine.

Not a terminal issue

The "Terminal/Shell" field does not really apply: there is no terminal
involved. The failing shell is Cowork's own sandboxed bash running on the
device (the device_bash tool). PowerShell was only used to collect the OS
build and hotfix evidence above.

Scope: host-side bridge is healthy, guest VM is not

Everything that does not go through the sandbox VM keeps working:

• get_device_info returns all five connected folders correctly
• device_list_dir returns folder contents normally
• device_stage_files / device_commit_files both work

The failure is isolated to attaching the Plan9 shares to the guest VM.

Relation to #92958

#92958 reports the same error string —
"sandbox-helper: no Plan9 drive shares mounted under /mnt/.virtiofs-root/shared"
— on Windows 11 ARM64, and traces it by A/B rollback to KB5124012
(build 28000.2954), where add_plan9_shares logs "completed" while attaching
zero shares.

This report is Windows 10 22H2 x64: a different OS, a different architecture
and a different KB, with the same guest-side symptom and the same break date
(September 2026 Patch Tuesday). That suggests the September 2026 cumulative
updates broke Plan9 share attachment more broadly, rather than #92958 being
an ARM64-specific defect.

To be explicit about evidence quality: I have not done an A/B rollback, so on
this machine the KB link is correlation. The window is one day wide and
nothing else changed.

Impact

Cowork sessions can still read and write files through the staging tools, but
cannot run anything on the machine — no scripts, no in-place edits, no renames
or moves. For file-organisation workflows that removes most of the value:
every operation becomes stage-to-cloud, process, commit-back, with renames and
moves left to the user by hand.

Asks

1. Is the add_plan9_shares silent-failure path in #92958 the same root cause

here, or a separate Windows 10 issue?

1. Is there a workaround short of uninstalling a security update? Windows 10

is on ESU now, so rolling back a cumulative update is a poor trade.

1. The error message gives no hint that a Windows update is involved.

Surfacing "host share attachment returned zero shares" at the point of
failure, instead of only the guest-side mount error, would make this
diagnosable.

Name               Ver                                     LastWriteTime
p9rdr.sys          NOT FOUND
p9np.dll           NOT FOUND
vmcompute.exe      10.0.19041.4522 (WinBuild.160101.0800)  2026/9/9 08:59:47   <-- replaced
computestorage.dll 10.0.19041.6807 (WinBuild.160101.0800)  2026/1/14 21:23:42  <-- untouched