claude-code - 💡(How to fix) Fix [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

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Error Messages/Logs

Root Cause

Root cause (isolated): The VM service logs its bundlePath as the un-virtualized user path:

Code Example

[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
RAW_BUFFERClick to expand / collapse

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?

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

  1. Install Claude Desktop for Windows (MSIX, v1.9659.2.0) as administrator.
  2. Open the Cowork tab and wait several minutes for the workspace to start.
  3. Run pwd in 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.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [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