claude-code - 💡(How to fix) Fix [BUG] Windows MSIX 3P mode: rootfs.vhdx commit fails, app self-terminates (beforeQuit) [3 comments, 2 participants]

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?

On Claude Desktop Windows MSIX 1.5354.0, Cowork in 3P mode (Bedrock managed configuration) consistently fails to commit rootfs.vhdx to disk. The app downloads the 2.2 GB rootfs.vhdx.zst to completion (last progress log shows 97.6% with "ETA 5s", followed ~7 seconds later by the start of vmlinuz.zst and initrd.zst parallel downloads — log interval is ~10 seconds, so the download actually reached 100%). Within 6 seconds of those parallel downloads starting, the app self-terminates via app.quit() — without any user action, OS signal, or system shutdown. The rootfs.vhdx commit step ([ClaudeCodeManager-VM] Installed at ...\rootfs.vhdx) never logs, indicating the failure is in the commit/install step, not the download itself. On restart, the VM image downloads are not retried, leaving the installation permanently stuck.

The same machine runs 1P mode correctly end-to-end (same MSIX build, same OS, same network, same user action pattern). Only the mode differs.

Log evidence points to the MSIX AppxManifest not registering the Claude-3p folder as a virtualized path, so the VM service's expected commit destination never auto-exists on disk.

Environment

Same-machine 1P vs 3P comparison

Single independent variable: mode. Everything else is identical. The 1P session passes through the exact same post-download moment where vmlinuz.zst and initrd.zst start in parallel (10:30:17-10:30:18) without self-terminating. The download-completion timing itself is not the trigger — the MSIX virtualization state is. In 1P, [VM] getVMStorageSubpath at 10:30:34 resolves the commit path successfully and the commit proceeds.

What Should Happen?

The VM bundle should commit to disk (same five files 1P produces: rootfs.vhdx, sessiondata.vhdx, smol-bin.vhdx, vmlinuz, initrd), the VM service should reach configure(), and workspace bash tools should work — just as 1P mode does on the same machine.

Error Messages/Logs

All fingerprints below appear in every 3P reproduction session.

**1. MSIX virtualization reports the Claude-3p path ABSENT**


[MSIX] Filesystem not virtualized — C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude-3p absent (likely Squirrel upgrade)


Compare with 1P mode on the same machine, same version:


[MSIX] Filesystem virtualization active — C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude exists


**2. rootfs.vhdx commit step never runs**

`[ClaudeCodeManager-VM] Installed at ...\rootfs.vhdx` is **never written** in any 3P session. The download reaches at least 97.6% (last progress log; log interval ~10s, so actual completion is ~100%), and the next step (parallel `vmlinuz.zst` / `initrd.zst` downloads) does start — proving the download itself finished. The failure is at the commit/install step:


10:04:07 [info] [download:3] 97.6% (2180.0/2233.9 MB) avg 10.90 MB/s, ETA 5s
10:04:14 [info] [download:4] Starting download from .../vmlinuz.zst
10:04:14 [info] [download:5] Starting download from .../initrd.zst
10:04:20 [info] beforeQuit: handler fired, going down


**3. Self-termination via beforeQuit (no user action, no OS signal)**


10:04:20 [info] beforeQuit: handler fired, going down
10:04:20 [info] beforeQuit: handler is not yet run, preventing quit and cleaning things up


Electron's `beforeQuit` is emitted by (1) user UI quit, (2) OS signal, (3) internal `app.quit()`. Paths 1 and 2 are ruled out (I did nothing; no system shutdown). Only path 3 is possible.

**4. VM service never reached configure()**


10:04:20 [warn] [HostLoop] VM boot failed; bash proxy unavailable:
    failed to set VHDX path:
    VHDX file not found: C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude-3p\vm_bundles\claudevm.bundle\rootfs.vhdx

10:04:20 [error] Failed to run onQuitCleanup(cowork-vm-shutdown):
    Error: not configured: call 'configure' first


The cleanup handler fails because `configure()` was never called. The VM service was waiting for a VHDX at the MSIX-virtualized path that, per fingerprint #1, does not exist.

**5. VM image downloads are never retried after the auto-restart**

After the auto-restart at 10:04:21, only the Linux CLI binary (`claude.zst`) is re-downloaded on each subsequent launch. `rootfs.vhdx.zst`, `vmlinuz.zst`, `initrd.zst` are never attempted again.

Full logs are attached (see Additional Information).

Steps to Reproduce

100% reliable on this machine.

1. Remove all Claude state (so we test a clean install):

   Get-Process -Name "Claude*","claude*","cowork*" -EA SilentlyContinue | Stop-Process -Force
   Get-AppxPackage -Name "Claude*" | Remove-AppxPackage
   Remove-Item -LiteralPath "$env:LOCALAPPDATA\Claude-3p"                          -Recurse -Force -EA SilentlyContinue
   Remove-Item -LiteralPath "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc"      -Recurse -Force -EA SilentlyContinue
   Remove-Item -LiteralPath "$env:APPDATA\Claude"                                  -Recurse -Force -EA SilentlyContinue
   Remove-Item -LiteralPath "HKCU:\SOFTWARE\Policies\Claude" -Recurse -Force -EA SilentlyContinue
   Remove-Item -LiteralPath "HKLM:\SOFTWARE\Policies\Claude" -Recurse -Force -EA SilentlyContinue

2. Install Claude Desktop MSIX from https://claude.com/download.
3. On the login screen, do not sign in. Open menu → Help → Troubleshooting → Enable Developer Mode.
4. Developer → Configure third-party inference:
   • Provider: Bedrock (AWS)
   • Region: us-west-2
   • AWS bearer token: (any valid token)
   • Model: global.anthropic.claude-sonnet-4-6
5. Apply locally. App restarts in 3P mode.
6. Do nothing else. Wait ~3-4 minutes.

Result: app self-terminates, restarts once, then stays unusable for workspace tasks forever on this install. Reproduced deterministically.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.121 (via Claude Desktop 1.5354.0)

Platform

AWS Bedrock

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Root cause hypothesis

The MSIX AppxManifest does not register Claude-3p as a virtualized folder, while it does register Claude.

Evidence chain:

1. [MSIX] Filesystem not virtualized ... Claude-3p absent is logged on every 3P start. The exact message states the virtualized path was not created.
2. 1P counterpart logs Filesystem virtualization active ... Claude exists on every 1P start — proving MSIX does auto-create virtualized paths, just not for Claude-3p.
3. The [VM] getVMStorageSubpath log in 1P resolves the subpath to the MSIX-virtualized %LOCALAPPDATA%\Packages\...\LocalCache\Roaming\Claude\claude-code-vm. The VM service expects to write VM bundle files into the MSIX-virtualized location.
4. In 3P, the equivalent virtualized location (...\LocalCache\Roaming\Claude-3p\vm_bundles\) does not exist, so the VM bundle commit has no destination. The rename/commit fails silently, the VM service never reaches configure(), and the app takes the app.quit() branch.
5. failed to set VHDX path: VHDX file not found ...\Claude-3p\vm_bundles\claudevm.bundle\rootfs.vhdx confirms the VM service was looking for the file in the MSIX-virtualized Claude-3p path and did not find it.

Alternatives ruled out

• Environment — 1P works on the same PC. Hyper-V role disabled in both cases. No EDR interference in logs.
• Timing / LAM race — 1P goes through the same post-download moment (parallel vmlinuz.zst / initrd.zst downloads after rootfs.vhdx.zst completes) without self-terminating. The download-completion timing itself is not the trigger.
• Dirty install state — reproduced on a clean, fresh install with all prior data removed.

Attachments

• 3p-failure-main.log.txt — extracted from %LOCALAPPDATA%\Claude-3p\logs\main.log, 3P failure session
• 1p-success-main.log.txt — extracted from %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\main.log, 1P success session on the same PC

Personal identifiers masked as <user>, <account-id>, <org-id>, <session-id>, <vm-instance-id>.

1p-success-main.log.txt 3p-failure-main.log.txt