[BUG] Cowork Linux sandbox never mounts on Windows MSIX — VM bundlePath resolves to un-virtualized Roaming\Claude while bundle data lives in the package container
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 Cowork Linux sandbox never starts on the Windows MSIX build of Claude Desktop. Every command (pwd, etc.) falls back to the file-tools layer and returns a Windows path instead of a /sessions/.../mnt/... path. The VM's disk image (rootfs.vhdx) never downloads — it stays at 0 MB and the VM loops indefinitely on download_and_sdk_prepare.
Root cause (isolated): The VM service logs its bundlePath as the un-virtualized user path:
bundlePath=C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
But under MSIX, all app writes are redirected into the package container, so the actual bundle data lives at:
C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\
The plain AppData\Roaming\Claude path does not exist (Test-Path returns False). The downloader reports "Downloading rootfs.vhdx... download already in progress, waiting..." against the literal Roaming\Claude path, while the integrity check reads "rootfs.vhdx missing" — because the two stages resolve to different folders. The result is an infinite loop with rootfs.vhdx pinned at 0 MB and the sandbox never mounting.
This appears to be a path-virtualization defect in the MSIX build, not a user misconfiguration. All virtualization features are enabled, the service is running, the network and disk are fine, and the bug survives uninstall/reinstall and app Reset. Related open issues (#55404, #55649, #56145, #57968) describe the same "service runs, VM never mounts" symptom but don't identify this bundlePath mismatch as the mechanism.
What Should Happen?
The Cowork Linux sandbox should start successfully so Claude can execute bash/Python commands. The VM should resolve bundlePath to the same package-virtualized location it writes to, download rootfs.vhdx, mount the sandbox, and pwd should return a /sessions/.../mnt/... path.
Error Messages/Logs
[Bundle:status] rootfs.vhdx missing
[warm] No warm file found for rootfs.vhdx at current version
[cache] No cached compressed file for rootfs.vhdx
rootfs.vhdx not found, downloading...
Downloading rootfs.vhdx...
[KernelBugMonitor] State reset
[VM:start] Beginning startup, bundlePath=C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
[VM:start] Bundle version: 5680b11bcdab215cccf07e0c0bd1bd9213b0c25d
[VM:steps] download_and_sdk_prepare started
[downloadVM] Download already in progress, waiting...
[startVM] VM startup already in progress, waiting...
--- KEY MISMATCH ---
VM service logs bundlePath as: C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle (this path does NOT exist; Test-Path = False)
Actual bundle data lives at: C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\
Under MSIX, app writes are redirected into the package container, so the downloader and the integrity check resolve to different folders -> infinite loop, rootfs.vhdx stuck at 0 MB.
Bundle folder contents (correct package path):
Name SizeMB
.wvm-tmp-XXXX
Steps to Reproduce
- Install Claude Desktop for Windows (MSIX, v1.9659.2.0) as administrator.
- Open the Cowork tab and wait several minutes for the workspace to start.
- Run
pwdin Cowork.
Expected: a /sessions/.../mnt/... path from the Linux sandbox.
Actual: a Windows path / file-tools fallback. The Linux sandbox never mounts.
rootfs.vhdx never downloads — it stays at 0 MB and the VM loops on "download already in progress, waiting..." indefinitely.
The bug also reproduces after every one of these recovery attempts:
- Restart-Service CoworkVMService
- Deleting the bundle, temp files, and .auto_reinstall_attempted marker (re-downloads, re-stalls at 0 MB)
- Full uninstall (Remove-AppxPackage), deleting data folders, reboot, reinstall as admin
- App > Advanced options > Reset, then reboot
Environment confirmed good throughout: VirtualMachinePlatform / HypervisorPlatform / Hyper-V-All all Enabled; CoworkVMService Running; download host reachable (Test-NetConnection storage.googleapis.com:443 = True); 20GB+ free disk; Controlled Folder Access off.
Claude Model
Opus
Is this a regression?
No, this never worked
Last Working Version
_No response_
Claude Code Version
N/A — Claude Desktop (Cowork) app, not Claude Code CLI. App version 1.9659.2.0 (MSIX).
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
N/A — Cowork desktop app (not a terminal). Underlying sandbox is the Hyper-V Linux VM that fails to mount.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗