Claude Desktop MSIX (v1.52386.0): Workspace fails to start — VHDX not found + junction redirect rejected, even after clean reinstall

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?

Environment

• Claude Desktop version: 1.52386.0 (1003ca), installed Sep 10, 2026
• Install method: Direct download from claude.ai/download (bootstrapper installs MSIX package Claude_pzs8sxrjxfjjc)
• OS: Windows 10 Pro, version 22H2, OS Build 19045.7663
• Subscription: ( Free)
• Hyper-V / Virtual Machine Platform: Enabled (confirmed via Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform → State: Enabled)

What's Wrong?

After enabling hardware virtualization to fix an initial HRESULT 0x80370102 (hypervisor not running) error, and running wsl.exe --install --no-distribution as suggested, the workspace still fails to start with a sequence of errors:

Error 1 — VHDX not found:

Failed to start Claude's workspace
failed to set VHDX path: VHDX file not found: C:\Users\meisa\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle\rootfs.vhdx
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace.

Error 2 — junction/leaf redirect rejected:

Private dir leaf redirects (junction/substitute-name plant): C:\Users\meisa\AppData\Local\Claude-3p\local-agent-mode-sessions\816458ad\00000000\5e81fdba\uploads-tmp (leaf canonicalizes to C:\Users\meisa\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\local-agent-mode-sessions\816458ad\00000000\5e81fdba\uploads-tmp, expected C:\Users\meisa\AppData\Local\Claude-3p\local-agent-mode-sessions\816458ad\00000000\5e81fdba\uploads-tmp)

Error 3 — model access error (possibly unrelated, appeared right after):

There's an issue with the selected model (claude-sonnet-4-6). It may not exist or you may not have access to it.

This looks like the same class of bug reported in #56542, #56626, and #55946 — a path mismatch between the plain user path (AppData\Local\Claude-3p\...) and the MSIX-virtualized container path (AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\...). Note my error path specifically uses the Claude-3p bundle folder (not Claude), matching #55946.

Steps to Reproduce

1. Fresh Windows machine, hardware virtualization disabled in BIOS initially
2. Enabled VT-x in BIOS/UEFI, restarted
3. Opened Claude Desktop, tried to start workspace/Cowork → got HRESULT 0x80370102
4. Ran wsl.exe --install --no-distribution as suggested
5. Restarted Claude — workspace now fails with VHDX not found (Error 1 above)
6. Retried — got junction redirect rejection (Error 2 above)
7. Fully uninstalled Claude Desktop, deleted %LOCALAPPDATA%\Claude, %LOCALAPPDATA%\Claude-3p, %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc, %APPDATA%\Claude
8. Reinstalled from claude.ai/download (fresh MSIX install, version 1.52386.0)
9. Same errors persist

What I Already Tried (all unsuccessful)

• Enabling hardware virtualization (VT-x) in BIOS
• Running wsl.exe --install --no-distribution
• Confirming Virtual Machine Platform is Enabled
• Full uninstall + manual deletion of all AppData folders + reinstall (still MSIX-based, no non-MSIX option exists)
• Checked for app updates — already on latest version (1.52386.0, installed the day before filing this report)

What Should Happen

The workspace/Cowork VM should locate and mount rootfs.vhdx and related bundle files consistently, without depending on a fragile junction between the plain AppData\Local\Claude-3p\... path and the MSIX-virtualized AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\... path.

Root Cause Confirmed (with evidence)

The Electron app process downloads and stores the VM bundle correctly under the MSIX-virtualized container path:

C:\Users\meisa\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\vm_bundles\claudevm.bundle\

I confirmed with Get-ChildItem -Force that all files are present and fully downloaded there, including a complete, valid rootfs.vhdx (7.6 GB uncompressed, matches expected size):

.auto_reinstall_attempted   (0 bytes)
.cowork-adopted             (40 bytes)
.initrd.origin / .initrd.zst.origin
.rootfs.vhdx.origin / .rootfs.vhdx.zst.origin
.vmlinuz.origin / .vmlinuz.zst.origin
initrd            (26.8 MB)
initrd.zst        (26.5 MB)
rootfs.vhdx       (7.6 GB)   <-- present and complete
rootfs.vhdx.zst   (1.1 GB)
sessiondata.vhdx  (548 MB)
smol-bin.vhdx     (36 MB)
vmlinuz           (14.3 MB)
vmlinuz.zst       (14.0 MB)

However, the native VM service (separate from the Electron process) looks for these files at the plain, non-virtualized user path:

C:\Users\meisa\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle\

This path does not exist at all (confirmed: Get-ChildItem on this path returns PathNotFound). This is why the error is specifically "file not found" rather than "corrupt file" — the file genuinely never gets written (or virtualization-redirected) to the path the native service reads from.

Log evidence (cowork_vm_node.log)

[info] [VM:start] Beginning startup, bundlePath=C:\Users\meisa\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle
[info] [VM:steps] download_and_sdk_prepare started
[info] [VM:steps] download_and_sdk_prepare completed (4ms)
[info] [VM:start] Copying smol-bin.x64.vhdx to bundle: ...\resources\smol-bin.x64.vhdx -> C:\Users\meisa\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle\smol-bin.vhdx
[info] [VM:start] smol-bin.x64.vhdx copied successfully
[info] [VM:start] Configuring Windows VM service...
[error] [VM:start] Startup failed: Error: failed to set VHDX path: VHDX file not found: C:\Users\meisa\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle\rootfs.vhdx
[info] [VM:start] Skipping auto-reinstall (already attempted once)

Notably download_and_sdk_prepare completed (4ms) — far too fast to have actually verified/prepared an 8+ GB bundle at the correct path. This suggests the app's internal state believes the bundle is ready (likely due to the .auto_reinstall_attempted flag) without validating that the files are reachable from the plain (non-package) path the native service reads.

Workaround I used to manually confirm the diagnosis (NOT a fix — for reproduction purposes only)

I manually created the plain-path directory and used robocopy (not a symlink/junction, since junctions are reportedly rejected by the VM service per #56542) to copy all 16 files (9.5 GB total) from the package-virtualized path to the plain path:

New-Item -ItemType Directory -Force -Path "C:\Users\meisa\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle"
robocopy "C:\Users\meisa\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\vm_bundles\claudevm.bundle" "C:\Users\meisa\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle" /E /COPY:DAT /R:2 /W:2

This confirms the bug is a pure path-resolution mismatch between the Electron app and the native VM service — not a corrupted or incomplete download.

Suggested Fix

The native VM service should resolve bundlePath through the same MSIX package-aware path resolution the Electron process uses (i.e., resolve to AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\vm_bundles\... instead of the plain AppData\Local\Claude-3p\vm_bundles\...), consistent with what #56626 already identified for the Claude (non-3p) bundle path.

Logs

(Full cowork_vm_node.log and custom3p-setup.log excerpts available on request — attaching relevant excerpts above. Full files located at:
C:\Users\<username>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\logs\)

Related Issues

#56542, #56626, #55946, #68543, #37094

What Should Happen?

The Cowork workspace should start successfully. Since rootfs.vhdx, initrd, vmlinuz, and sessiondata.vhdx all download completely and correctly (confirmed: 7.6 GB rootfs.vhdx present and intact), the native VM service should be able to locate them and mount the VM without any "file not found" error.

Specifically, the native VM service should resolve the bundle path the same way the Electron app does — i.e., through the MSIX package-aware path (AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\vm_bundles\...) — instead of looking for a plain, non-virtualized path (AppData\Local\Claude-3p\vm_bundles\...) that is never populated. This is the same class of path-resolution bug already identified in #56626 for the non-3p Claude bundle.

Error Messages/Logs

Steps to Reproduce

1. Fresh Windows 10 Pro (22H2, build 19045) machine, hardware virtualization (VT-x) initially disabled in BIOS
2. Installed Claude Desktop (direct download from claude.ai/download, which installs the MSIX package)
3. Opened Claude Desktop, tried to start workspace/Cowork

→ Error: "Claude's workspace failed to start with HRESULT 0x80370102 (hypervisor not running)"

1. Enabled VT-x in BIOS/UEFI, restarted
2. Ran wsl.exe --install --no-distribution (as suggested by Claude in-app)
3. Reopened Claude Desktop, tried workspace again

→ Error: "failed to set VHDX path: VHDX file not found: C:\Users\<user>\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle\rootfs.vhdx"

1. Retried

→ Error: "Private dir leaf redirects (junction/substitute-name plant): ...\uploads-tmp (leaf canonicalizes to ...\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\...\uploads-tmp, expected ...\AppData\Local\Claude-3p\...\uploads-tmp)"

1. Fully uninstalled Claude Desktop via Settings > Apps
2. Manually deleted: %LOCALAPPDATA%\Claude, %LOCALAPPDATA%\Claude-3p, %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc, %APPDATA%\Claude
3. Restarted computer, reinstalled Claude Desktop fresh (version 1.52386.0)
4. Tried workspace again → same "VHDX file not found" error persists
5. Inspected the actual bundle folder via PowerShell:

• C:\Users\<user>\AppData\Local\Claude-3p\vm_bundles\claudevm.bundle → does not exist (PathNotFound)
• C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Local\Claude-3p\vm_bundles\claudevm.bundle → contains a complete, valid rootfs.vhdx (7.6 GB) and all other required files

1. Confirmed via cowork_vm_node.log that the app reports bundlePath as the plain (non-package) path, which the native VM service cannot find, while the actual files exist only under the MSIX-virtualized package path

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

1.52386.0 (1003ca

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_