Claude Desktop 1.11187.4 - native crash in Cowork/Secure-VM bootstrap on Windows (single-drive C:, not EXDEV)

Claude Desktop — Crash Report: native crash in Cowork/Secure-VM bootstrap

Summary

The Claude desktop preview build 1.11187.4 (MSIX, developer-signed, deployment_mode: 1p)
crash-loops on Windows. The app launches and renders its window normally, but a few seconds
after login it begins the Cowork / local-agent "Secure VM / full VM sandbox" bootstrap —
downloading rootfs.vhdx.zst — and the main process crashes natively at ~3–4% of the download,
~15–35 s after launch. Because it crashes before the download completes, it never finishes and
re-downloads from scratch every launch → permanent crash loop. The app is unusable.

The stable consumer build 0.14.10 does not have this feature and runs perfectly, which is the
current workaround — but it lacks the Code/Cowork tabs.

Crash nature: native, not JavaScript

• Sentry local state after each crash: session.json → status: "ok", errors: 0; queue-v2.json → [].

A JS exception would have been captured — it was not.

• Each crash produced only a ~35 MB Crashpad minidump (the JS error handler never fired).
• Right before the crash, main.log logs [event-loop-stall] main process blocked for 1258ms on the

main/browser process, immediately following the rootfs.vhdx download start.

Reproduction (100%, 4 occurrences captured)

1. Launch build 1.11187.4. Window renders (~2.8 s, main_view_dom_ready_ms: 2834).
2. Log in (Google OAuth).
3. On login, Cowork init runs: cowork_vm_node.log → rootfs.vhdx missing → Downloading rootfs.vhdx...

(GET https://downloads.claude.ai/vms/linux/x64/5680b11bcdab215cccf07e0c0bd1bd9213b0c25d/rootfs.vhdx.zst).

1. Main process crashes ~3–4% into the download. Crashpad writes a minidump; app exits.

Crash dumps observed (local copies removed during uninstall; should exist server-side via Crashpad/Sentry):
| Dump ID | Time (local) | Size |
|---|---|---|
| 02ac4f5e-120d-4aa0-aa69-7de2dd4dfc47 | 2026-06-06 19:26:35 | ~35 MB |
| ecc46c98-54fe-42dd-b657-215f99d687de | 2026-06-06 20:04:30 | ~35 MB |
| 61da537f-0809-48cf-a226-59594ad30160 | 2026-06-06 20:23:41 | ~35 MB |
| 25f66021-5af5-41d7-9c06-daa2310e7524 | 2026-06-06 20:43:23 | ~35 MB |

Sentry/Crashpad correlation: install/device id b765f26d-f19f-40d2-bcf5-b5e2cfabae84
(account / org UUIDs available on request).

What was ruled out (so this is not an environment/AV issue)

• Antivirus (Norton 360 for Gamers): crash persists with all Norton protections turned off and with

Claude folders added to Norton scan + Auto-Protect/SONAR/Download-Intelligence exclusions. (Windows
Defender is in passive mode.)

• MSIX filesystem virtualization: crash persists when pointing CLAUDE_USER_DATA_DIR at a clean,

non-virtualized real folder.

• Disk space: 1.5 TB free. RAM: 49 GB free at crash (app_memory ~1.5 GB).
• Corrupt install: Get-AppxPackage Status: Ok; window renders fine; reproduced on a fresh data dir.

Secondary signals (possibly related)

• spawn EBUSY (errno -4082) spawning the freshly-downloaded helper

…\Roaming\Claude\claude-code\2.1.165\claude.exe — the spawn is attempted before the download
finishes ([CCD] Binary preflight: .verified marker missing but binary exists … Proceeding with spawn).
Looks like a race between helper-download completion and helper-spawn.

• WER RADAR_PRE_LEAK_64 on a leftover claude.exe.old.<timestamp> (v2.1.142.0) — an interrupted

helper auto-update left a leaking .old binary.

• All three GPUs report active: false in the Sentry context (NVIDIA RTX 5080, AMD Radeon iGPU,

MS Basic Render Driver) — i.e. no active GPU acceleration at crash time.

Environment

• App: Claude desktop 1.11187.4 (x64), package Claude_1.11187.4.0_x64__pzs8sxrjxfjjc,

SignatureKind Developer, build_type: windows-store, deployment_mode: 1p.

• Runtime: Electron 41.6.1, Chromium 146.0.7680.216, Node 24.15.0; bundled claude-code 2.1.165.
• OS: Windows 11 Pro, build 26200.
• CPU/RAM: AMD Ryzen 9 9950X3D (16C/32T), 64 GB.
• GPU: NVIDIA RTX 5080, driver 32.0.16.1047; AMD Radeon iGPU.
• Virtualization: VirtualMachinePlatform = Enabled, WSL2 = Enabled (distros: Ubuntu,

docker-desktop). Likely relevant since the Secure-VM feature uses the Windows Hypervisor Platform.

• AV: Norton 360 for Gamers active (Defender passive) — ruled out as cause (see above).

Impact / ask

The only build with the Code/Cowork tabs (1.11187.4) is unusable due to this native crash; the only
stable build (0.14.10) lacks the feature. Request: fix the native crash in the Secure-VM/Cowork
bootstrap on Windows (the rootfs.vhdx download path, main process), and/or provide a way to disable
the auto VM download so the app stays usable when the sandbox can't initialize.

Update — EXDEV / storage-location cause RULED OUT for this machine

Anthropic support suggested the crash may be the known EXDEV: cross-device link not permitted
issue (VM download crossing drive boundaries when "new content saves to D:"). That does not apply
here — verified:

• The machine has only one drive, C: (3725 GB). There is no D: (or any other) volume.
• TEMP / TMP / .NET temp → all C:\Users\osubo\AppData\Local\Temp.
• System TEMP → C:\WINDOWS\TEMP. Default Appx install volume → C:\Program Files\WindowsApps

(system volume). All known folders on C:.

• A prior repro pointed CLAUDE_USER_DATA_DIR at a clean C:\Users\osubo\ClaudeData and still crashed.

Since every path is on a single NTFS volume, a cross-device link is impossible — so this is a
distinct native crash, not the EXDEV case. VirtualMachinePlatform is enabled. The other two
support workarounds also don't apply (no D: to move; secureVmFeaturesEnabled:false requires an
Enterprise admin policy, not available on this account).

Workaround in place

Reverted to stable consumer build 0.14.10 (runs clean). Using the Claude Code CLI for coding in
the meantime.