[BUG] Cowork Windows x64: KB5124008 (26200.9445) breaks Plan9 share mount — confirmed by A/B uninstall

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?

The 2026-09 Windows cumulative update KB5124008 (OS build 26200.9445, Windows 11 25H2, x64) breaks the Cowork workspace. Every shell call fails because the Plan9 shares never attach.

Confirmed by A/B test: uninstalling KB5124008 and restarting restored Cowork immediately and completely. Nothing else was changed. Reinstalling the update would be expected to break it again.

The VM itself starts. The failure is that the share is then reported as not mounted. It fails on share "c" first — the session's own outputs and
uploads directories under AppData — so the workspace aborts before the user's other connected drives (H:, E:) are ever attempted. Adding, removing or re-adding folders makes no difference; the fault is below the folder layer.

A second line on the recovery path suggests stale state is being reused rather than a clean workspace being built:

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

Why this is not a duplicate

Issue #92958 covers the same class of failure on ARM64, triggered by KB5124012 and confirmed by rollback. This is the x64 / 25H2 counterpart:
different KB (KB5124008), different build line (26200 vs 28000), same month's cumulative update, same silent-attach failure, same A/B confirmation.

Related: #72685, #43290, #43896, #31988, #32828.

What Should Happen?

The Plan9 shares should attach and the Cowork workspace should start, as it did on this same machine and same Claude build a few hours earlier the same day, before KB5124008 installed.

Error Messages/Logs

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/<ids>/outputs as outputs: source path /mnt/.virtiofs-root/shared/c/Users/<user>/AppData/Local/Packages/Claude_pzs8sxrjxfjjc/LocalCache/Roaming/Claude/local-agent-mode-sessions/<ids>/outputs is under Plan9 share "c" which is not mounted;

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

--- notes ---

The failing mount alternated between "outputs" and "uploads" across attempts,
both under share "c", which is consistent with the share being absent rather
than one directory being unreadable.

No application log could be supplied, and that may be a second bug: on this
machine %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\
contains nothing newer than 21 August 2026, including cowork_vm_node.log, which
is the file that would have captured this. Either logging has stopped or the
location moved in a recent build. Happy to supply logs if told where current
ones are written.

Steps to Reproduce

1. Windows 11 25H2 x64 with Cowork working normally (verified working at 03:29

on 9 September 2026 — a long batch job ran fine).

1. Install KB5124008 (OS build 26200.9445). It arrived through normal Windows

Update the same day.

1. Open Cowork and run any shell command. It fails every time, in every

conversation, including brand-new ones created after the failure started.

1. Uninstall KB5124008 (Settings → Windows Update → Update history → Uninstall

updates) and restart.

1. Cowork works again immediately — shell, Python, LibreOffice, and all

connected drives.

Steps 2–5 were performed in that order on one machine, so the correlation is a
direct A/B, not an inference.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.49585.0

Claude Code Version

1.49585.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment

• Windows 11 Pro, version 25H2, OS build 26200.9445 (with KB5124008)
• x64
• Claude Desktop installed as MSIX, package family Claude_pzs8sxrjxfjjc
• The shell that fails is Cowork's built-in Linux workspace shell, not a

terminal launched by the user. The Terminal/Shell dropdown has no option for
it.

Note on the version fields

The Claude version did not change. The regression was triggered by Windows OS build 26200.9445 (KB5124008); the last working state was the same Claude build on OS build 26200.9168.

Troubleshooting already ruled out — none of these helped while KB5124008 was installed:

• Closing and reopening the app
• A full quit rather than closing the window
• A complete computer restart
• Starting a brand-new Cowork conversation, which failed identically. This rules out per-session state and is worth noting: the workspace name is tied to the conversation, so a new conversation gets a new workspace and still failed.
• Disconnecting and re-adding the folders

Uninstalling KB5124008 fixed it on the first attempt.

Impact

The workspace is where the preinstalled toolchain lives (Python, LibreOffice, poppler, qpdf), so with the update installed no local file processing is
possible at all. File read and write through the transfer route keeps working, which makes this easy to misdiagnose as a folder-permission problem rather than a hypervisor one — I spent several hours on folder-level troubleshooting before looking at Windows Update.

Workaround

Uninstall KB5124008 and pause Windows Update. Note that Windows only allows a pause of about five weeks, so this is not a durable workaround for anyone who depends on Cowork.