[BUG] Cowork local sandbox not mounting after update in Claude Desktop 1.49585.0.0 (Windows)

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 local sandbox: guest mounts 3/3 Plan9 shares, host still reports
share "c" not mounted. Regression in Claude Desktop 1.49585.0.0 (Windows).

What Should Happen?

WORKED on 1.46388.4.0. BROKE on 1.49585.0.0, auto-installed 2026-09-08 14:35.
Windows 11 Pro 26200. MSIX package Claude_pzs8sxrjxfjjc, installed from the
.exe from claude.ai, not the Store.

Error Messages/Logs

SYMPTOM: every bash/workspace call fails with
  failed to mount <path>\outputs as outputs: source path ... is under
  Plan9 share "c" which is not mounted
The path is the MSIX-redirected one:
  AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\...

Steps to Reproduce

BOTH SIDES REPORT SUCCESS. This is the core of the report.
Host cowork-service.log:
[VM] Sent plan9Shares notification (3 shares)
[HCS] HcsModifyComputeSystem returned: hr=0x0
[RPC] API reachability: REACHABLE
Guest coworkd log:
[hyperv] Plan9 share "c" mounted at /mnt/.virtiofs-root/shared/c
[hyperv] Plan9 share "d" mounted ...
[hyperv] Plan9 share "z" mounted ...
[hyperv] mounted 3/3 Plan9 shares
[coworkd] connected, waiting for commands
The guest has the share. The per-session bind mount says it does not.

NOT the documented failure modes. The service starts, the VM boots, network
is CONNECTED, 71 CA certs install, API is REACHABLE. No error 87, no exit
1066, no DCOM 10016, no HNS hang.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

1.46388.4.0

Claude Code Version

1.49585.0.0

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

RULED OUT, each tried and each still failing:

• Full Windows restart
• sc.exe stop/start CoworkVMService
• Bypassing packaged activation entirely: registered cowork-svc.exe as an

ordinary Win32 service per issue #86140. Service runs, same failure.

• A brand new Cowork session
• Killing the VM worker process (vmwp.exe) to force a new guest
• Renaming vm_bundles to force a fresh VM image download. Confirmed

effective: the guest uid for the same username changed from 1006 to
1001, proving a new session disk and user table. Same failure.

POSSIBLY RELATED, from issue #86140's adjacent defects:
"StartVMWithBundle receives the unredirected bundle path while configure
passes the MSIX-redirected one."
The host also logs, on every connect:
[Server] Reusing existing session for <user>:C:\Users\<user>\AppData\Local\
Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude
which is the redirected path. A redirected-vs-unredirected mismatch between
what is shared and what is bind-mounted fits every symptom above.

IMPACT: the local workspace shell is unusable. File tools still reach the
connected folder, so the folder is fine and only the sandbox is dead.