[BUG] Claude Desktop (Cowork) on Windows 11: Linux sandbox fails to start — Plan9 share "c" not mounted after KB5124008

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?

Surface: Claude Desktop app (Cowork mode) on Windows 11 — not the Claude Code CLI. Filing here because there is no separate tracker for the desktop app.

Summary

Since Windows update KB5124008 (build 26200.9445), the Claude Desktop Linux
sandbox no longer starts. The VM itself comes up, but it never gets access to
drive C:. Every shell command fails, which takes down all Python-based
processing — most importantly, reading and writing .docx files.

Two distinct failures are involved (see below). Fixing only the first one leaves
the second as a blocker.

OS | Windows 11 Pro, build 26200.9445
Triggering update | KB5124008, installed 2026-09-08 21:34
Claude Desktop | 1.49585.0
Affected component | Linux sandbox / workspace VM (bash tool)
First occurrence | 2026-09-09, first launch after the update
Reproducibility | 100% — every launch since

What Should Happen?

The sandbox starts, mounts the outputs directory, and executes shell commands.

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/Roaming/Claude/
local-agent-mode-sessions/<session>/<workspace>/<local>/outputs as outputs:
source path ... is under Plan9 share "c" which is not mounted;

create: RPC error -1: ensure user: user <session-user> already exists
unexpectedly: uid=1153 gid=1153

## Two separate failure modes

**1. Mount failure (root cause).** The Plan9 share `c` is not mounted. The attach
step reports success beforehand, but nothing is actually attached. The failure only
surfaces later, inside the VM, with no diagnostic at the point of origin. This
strongly suggests a return value is not being checked on the attach path.

**2. Orphaned VM user (follow-on failure).** The `create` fallback path fails
because the session user from an earlier aborted run still exists (uid=1153).
This blocks VM re-creation independently of the mount problem — so even once the
share issue is resolved, this stale state can keep the sandbox down.

Steps to Reproduce

1. Windows 11 with KB5124008 installed (build 26200.9445).
2. Launch Claude Desktop, open any session.
3. Run any shell command, e.g. echo OK.
4. → Error as above. Restarting the app and the OS makes no difference.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.260

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Timeline

• 2026-09-08, all day: sandbox works normally.
• 2026-09-08, 21:34: KB5124008 installs.
• 2026-09-09, first launch afterwards: failure appears, and on every launch since.

Ruled out

Checked and healthy:

• Windows itself, Hyper-V, the vmcompute service, free disk space.
• Plain file access from the app to Windows still works.
• App restart and full OS reboot change nothing.

Impact

Complete loss of shell access and therefore of all Python-backed processing:
no .docx handling, no skill scripts, no data processing. For document-centric
work the application is effectively unusable.

Suspected cause

The trigger is a behavior change in KB5124008. The underlying fragility is that
the sandbox mounts the host filesystem through an internal Windows interface whose
behavior Microsoft does not guarantee as stable. KB5124008 lists no known issues
and there is no official error code, so this is not tracked on the Microsoft side.
A fix will have to come from Anthropic.

Other affected users

Six similar reports appeared within two days of this update, against one in the
entire preceding week. In one of those cases the correlation was confirmed by
rolling the update back and forward again.

Workarounds

• Roll back KB5124008 — resolves the issue but gives up the security fixes

shipped in that update. Not an option on a working machine.

• Work without the sandbox — exchange documents through Word as .txt

(export with UTF-8 encoding explicitly selected; Word defaults to ANSI and
corrupts non-ASCII characters). Works, but loses all formatting.

What this report does not establish

Whether the defect lies in the mount call itself or in its error handling cannot
be determined from the outside. The success message on attach points to an
unchecked return value, but that cannot be confirmed without access to the source.