[Claude Desktop, not CLI] Windows: main process killed at loader time on every launch after first successful run post-install

Note: This report is about Claude Desktop (the Windows app distributed from claude.ai, package Claude_1.17377.1.0_x64__pzs8sxrjxfjjc), not the Claude Code CLI. I could not find a dedicated public tracker for Claude Desktop, so filing here — please redirect if there's a better place for this.

Summary

After a fresh install (or reinstall) of Claude Desktop, the app launches successfully exactly once. After closing it normally, every subsequent launch attempt fails completely silently — no window, no error dialog, no crash report anywhere in Windows. A full uninstall + reinstall temporarily fixes it for one more launch, then the same failure recurs.

Environment

• Windows 11 Home (build 10.0.26200), x64 — no vmms (Hyper-V Virtual Machine Management) service present on this SKU, only the lightweight "Virtual Machine Platform"/HCS APIs used by WSL2
• Claude Desktop version 1.17377.1.0 (MSIX package Claude_1.17377.1.0_x64__pzs8sxrjxfjjc)
• Installed via the installer from claude.ai (not Microsoft Store)
• Windows Defender real-time protection disabled, no third-party AV installed
• Smart App Control: Off

Reproduction (100% reliable on this machine)

1. Fresh install of Claude Desktop
2. Launch from Start Menu → succeeds, window opens normally
3. Close the app normally
4. Launch again from Start Menu → silently fails (no window, no dialog, nothing)
5. Every subsequent attempt fails the same way until a full uninstall + reinstall, which resets it to step 2 for exactly one more successful launch

Diagnostics already ruled out

• Get-AppxPackage Status: Ok; Authenticode signature on both Claude.exe and app\resources\cowork-svc.exe: Valid
• File ACLs identical and correct between Claude.exe and cowork-svc.exe
• No stale/zombie processes, no Singleton*/*.lock files in the per-user profile (%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude)
• Tested with a completely fresh (renamed-away) profile folder — failure still reproduces identically, so it is not per-user profile/cache corruption
• All JSON config files in the profile (config.json, claude_desktop_config.json, Preferences, Local State, etc.) are valid JSON; manually removing a suspicious "lastSeenRequireCoworkFullVmSandbox": null key from config.json did not fix it
• CoworkVMService (the packaged Windows service backing the "cowork" VM/sandbox feature) is registered correctly (LocalSystem, AUTO_START, correct binPath after reinstall) and behaves identically and correctly in both the working and broken cases — it reaches "Service ready, listening on \\\\.\pipe\cowork-vm-service" every time
• hcsdiag list shows no orphaned/leftover Claude-related compute systems (only an unrelated WSL utility VM)
• No relevant entries in Microsoft-Windows-CodeIntegrity/Operational, Microsoft-Windows-AppLocker/EXE and DLL, or the Application log around failed launch attempts

Key evidence: cowork-service.log

Working launch — main process successfully connects to its own VM helper service:

[Server] Client connected
[Server] Client signature verified: ...\app\claude.exe (subject: Anthropic, PBC)
[Server] Client connected: user=<user> exe=claude.exe isDev=false
[VM] VM owner set: id=cowork-vm-3bda1ea7 ...
[Server] Created new VM session for <user>:...\LocalCache\Roaming\Claude
[Server] Persistent RPC: entering loop
... (session runs for ~38s) ...
[Server] Persistent RPC: connection ended: failed to read length: EOF   <- app closed normally
Service stop requested / Service stopped / restarts, back to "ready"

Broken launch — service reaches "ready" and never receives any connection at all:

Service ready. Listening on \\.\pipe\cowork-vm-service
(nothing further -- no "Client connected" line ever appears for this attempt)

This shows the main Claude.exe process fails before it ever attempts to talk to its own VM helper service, i.e. very early in its own startup.

Root cause found via Process Monitor

Captured a full Procmon trace across a failing launch attempt. Sequence for the Claude.exe process from creation to death (all within ~42 ms):

Process Create   C:\...\app\Claude.exe   SUCCESS   PID: 15028
Thread Create    Thread ID: 12416
Load Image       C:\...\app\claude.exe   SUCCESS
Load Image       C:\Windows\System32\ntdll.dll   SUCCESS
CreateFile / Read / Close   C:\Windows\Prefetch\CLAUDE.EXE-....pf   (standard OS prefetch, not app code)
Thread Exit      Thread ID: 12416
Process Exit     Exit Status: -1073741823  (0xC0000001 / STATUS_UNSUCCESSFUL)

Notably, kernel32.dll is never loaded, and no module besides the process's own image and ntdll.dll loads before the thread/process exit. This means the process dies at the very earliest point of the Windows loader, before any application code (Electron/Node/V8/Chromium init) could plausibly run. No other process in the trace touches this PID (checked by grepping the full capture for PID 15028), and there is no corresponding crash/WER event anywhere in Event Viewer — it is a clean, silent, extremely early exit, not a normal application crash.

This exact signature (clean, instant, pre-kernel32 death, STATUS_UNSUCCESSFUL) reproduces on every single launch after the first successful one, and never on the first launch after a fresh install/reinstall.

Most thorough cleanup attempted (still did not fix it)

Beyond a plain uninstall/reinstall cycle, also tried: explicitly sc delete-ing the CoworkVMService registration (it turned out Remove-AppxPackage had already cleaned it up correctly — no leftover service or registry key), plus fully deleting %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc and C:\ProgramData\Claude before reinstalling from a completely clean slate. The exact same pattern still reproduced: first launch after reinstall worked, closing and relaunching failed again with the identical silent/no-window symptom.

Possible relation to Windows Home + Cowork VM sandbox

Found a community writeup (https://www.betterclaw.io/blog/claude-cowork-not-working-windows) describing several distinct Windows-specific Cowork failure modes, including one specifically about Windows 11 Home lacking the full Hyper-V stack (vmms) that a "full VM sandbox" mode may require. This machine is Windows 11 Home and genuinely has no vmms service. I couldn't fully confirm this explains this specific crash signature though — a missing service dependency would more plausibly surface as an in-app error after the JS/Electron runtime starts, not as a pre-kernel32.dll loader-level death — but it seemed worth flagging as a possibly-related environment factor, especially since a lastSeenRequireCoworkFullVmSandbox cache key (which sounds related to exactly this capability check) is the only per-run-created config value I could find that correlates with the working → broken transition (see above; manually clearing it alone didn't fix the crash, but the underlying capability-detection logic around it seems like a reasonable place to look).

Suspicion

Something in app or OS-level state that gets created only after a first successful run — possibly related to the "cowork full VM sandbox" feature (a lastSeenRequireCoworkFullVmSandbox key appears in config.json only after the first run) or possibly a Windows Job Object / FullTrustApplication packaging lifecycle artifact that isn't cleaned up between launches — causes every subsequent process creation for Claude.exe to be killed essentially before it starts. I wasn't able to pin down the exact trigger further without source-level access or a kernel debugger. Happy to provide the full Procmon capture or run more diagnostics if useful.