[BUG] Cowork Windows: device_bash still cannot mount connected folders AFTER KB5129195 — patched 25H2 build 26200.9457, rebooted, fresh session, fresh folder attach

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?

KB5129195 is documented as the fix for the KB5124008 Plan9 regression (#92984, #94869). On this machine it is installed, the host is on a fixed build, the machine has been rebooted, and device_bash still cannot mount connected folders.

Crucially, this was retested in a brand-new Cowork session with the folder attached for the first time on the already-patched host — so no stale sandbox or stale share state from the broken period is involved. Every existing report in the threads above is from a machine still on the unpatched build, so this appears to be a case not yet reported.

Environment

Claude Desktop	2.110.0 (Electron 44.2.0, Node 24.20.0)
OS	Windows 11 25H2, build 26200.9457
Fix status	KB5129195 installed 2026-09-15
Last reboot	2026-09-19 06:24:37 local
Guest kernel	Linux claude 6.8.0-138-generic #138~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC x86_64
Connected folder	G:\My Drive (Google Drive for Desktop, stream mode)
Originally broke	2026-09-08 with KB5124008 (build was then 26200.9445)

26200.9457 is the build listed in #94869 as carrying the 25H2 fix.

What still works: device_list_dir, device_stage_files and device_commit_files all operate normally against the same folder — listing, reading and writing succeed. The failure is isolated to the device_bash mount path, exactly as in the pre-patch reports.

Already ruled out on this machine

• Not the firewall. Inbound "File and Printer Sharing (SMB-In)" was enabled for Private/Public/Domain and the network profile set to Private (verified Enabled=True). No effect — and Plan9/virtiofs does not traverse SMB anyway. Noted only so others don't repeat it.
• Not app state. Folder disconnected and reconnected, desktop app fully restarted, host rebooted.
• Not session age. See the two configurations under Steps to Reproduce.
• Not a missing patch. Get-HotFix -Id KB5129195 returns INSTALLED; build is 26200.9457.

What Should Happen?

With KB5129195 installed and the host rebooted, a connected folder should mount inside the session VM and be visible under $HOME/mnt/, so device_bash can read and write it — the behaviour before KB5124008.

Secondarily: when the guest-side mount fails, the UI should say so. The folder currently displays as connected and the file tools work, so nothing indicates the shell is blind to it until a command fails.

Error Messages/Logs

$ echo "shell: ok"; ls -la $HOME/mnt/
shell: ok
total 8
drwxr-xr-x 2 nobody     nogroup     4096 ...
drwxr-x--- 6 rcw-<sid>  rcw-<sid>   4096 ...

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

$ ls "$HOME/mnt/My Drive/Vault"
ls: cannot access '/sessions/rcw-<sid>/mnt/My Drive/Vault': No such file or directory

$ ls /mnt/.virtiofs-root/shared
ls: cannot access '/mnt/.virtiofs-root/shared': Permission denied

$ uname -a
Linux claude 6.8.0-138-generic #138~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC x86_64 GNU/Linux

PS> $cv=Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion"
PS> "Build $($cv.CurrentBuild).$($cv.UBR) $($cv.DisplayVersion)"
Build 26200.9457 25H2
PS> "KB installed: $((Get-HotFix -Id KB5129195).InstalledOn)"
KB installed: 09/15/2026 00:00:00
PS> "Last boot:    $((Get-CimInstance Win32_OperatingSystem).LastBootUpTime)"
Last boot:    09/19/2026 06:24:37

Steps to Reproduce

1. Windows 11 25H2 on build 26200.9457 with KB5129195 installed; reboot.
2. Start a new Cowork session in Claude Desktop.
3. Attach a local folder with Add folder (here: G:\My Drive).
4. Run any device_bash command that lists $HOME/mnt/ — e.g. echo test; ls -la $HOME/mnt/.
5. The shell runs, $HOME/mnt/ is empty, and the "failed to mount" note is returned. The folder is simultaneously listable via device_list_dir.

Two configurations were tested, both fail identically:

1. A session created 2026-09-14 — before the KB and before the reboot. Hypothesis was that its sandbox carried stale mount state from the broken host.
2. A brand-new session created 2026-09-19 on the patched, rebooted host, with the folder attached fresh via Add folder for the first time in that session.

Configuration 2 rules out stale sandbox/session state. The attach is being performed for the first time on a fully patched host and still produces no guest mount.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.269 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Asks

1. Confirm whether KB5129195 is expected to fully resolve this, or whether a Cowork-side change is also required — the existing threads imply the KB alone is sufficient, and on this machine it is not.
2. If a Cowork-side fix is needed, harden the Plan9 attach so it does not depend on the host HCS behaviour that changed.
3. Surface the guest-side mount failure in the UI rather than showing the folder as connected.

Impact / workaround

Not a hard blocker — file work still goes through device_stage_files / device_commit_files, and anything genuinely needing a shell gets written as a PowerShell script and run by hand. Both are slower and neither can use device-only tooling.

One safety note for anyone landing here: several reports mention people resorting to Reset Application Data, which permanently deletes session history. It does not fix this, and it costs you the transcript.

Related: #92984 (original KB5124008 regression) · #94869 (KB5129195 fix and the branches it covers) · #93442, #93071, #92985, #93221 (same symptom, unpatched hosts)

Start at the device_bash mount path and reproduce the failure with a fresh Cowork session on Windows 11 build 26200.9457, using ls -la $HOME/mnt/ and the reported connected-folder configuration. Compare the guest mount result with device_list_dir, device_stage_files, and device_commit_files; done means the folder mounts in the shell or the UI clearly reports the mount failure.