[BUG] Claude Desktop Windows (MSIX 1.22209.3.0, CC 2.1.215): renderer bootstrap crash-loop, Cowork sessions-bridge wedges, unreaped claude.exe children — daily forced restarts on a Max 20x plan

Environment

• Windows Server 2025 Standard (build 10.0.26100), 64 GB RAM
• Claude Desktop MSIX package Claude_1.22209.3.0 (WindowsApps), embedded Claude Code runtime 2.1.215; standalone CLI 2.1.198 also installed
• Heavy daily Cowork/Claude Code usage with a large MCP fleet; Max 20x plan

Summary

Claude Desktop has required force-close + relaunch at least daily (often several times a day) for weeks. Logs show three recurring app-side failure modes, plus one minor startup error. (A fourth failure mode turned out to be our own janitor script killing app worker processes, a direct consequence of failure mode 3; noted at the end for completeness.)

1. Renderer sandbox bootstrap failure -> black/dead window crash-loop

From LocalCache\Roaming\Claude\logs\unknown-window.log: 42 occurrences 2026-06-30 to 2026-07-09, worst cluster 22 on 07-08:

[error] Electron sandboxed_renderer.bundle.js script failed to run
[error] TypeError: Cannot destructure property 'preloadScripts' of 'binding.startupData' as it is null.

Accompanied by hundreds of renderer reload events. The window goes black/unresponsive and only a full app restart (including tray exit) recovers it. No Crashpad dump is produced (it hangs rather than hard-crashes). The host is not under pressure when this happens (RAM ~50%, CPU low).

2. Cowork sessions-bridge reconnect storms wedge chats until restart

main.log shows sessions-bridge log storms (~950 and ~1,088 matching lines on 2026-07-19 and 07-20 alone). In earlier (June) captures this ends with AcknowledgeWork failing repeatedly with 409 Conflict ("must be in QUEUED state... Current state: starting"), the 6-attempt reconnect cap plus redispatch budget exhausting, and the transport staying dead until app restart: the chat spinner runs forever while the window itself stays alive. The web layer concurrently logged 503 "... reset reason: overflow" on /v1/code/sessions.

3. claude.exe fan-out children are never reaped (Windows)

Related to #1935 but claude.exe-specific: subagent/utility claude.exe children accumulate as idle leaves after their work completes. We've observed 54 processes / 19.5 GB RSS before intervention; 12 more leaked just overnight 2026-07-20 to 07-21. Because the product never reaps them, we run an external hourly janitor.

That janitor is also a cautionary tale for anyone else doing the same: after the MSIX architecture change, the Desktop app's own live workers (Cowork session hosts, heavy-work, file-index; AppData\Roaming\Claude\claude-code\<ver>\claude.exe) are structurally identical to leaked children (leaf process, live parent, running more than 3h), and our janitor killed them hourly. One second later main.log records Sentry caught: "'Utility' process exited with 'killed'" and heavy-work/file-index worker deaths. We've since fixed our script with path-based protection, but two product asks follow:

1. Reap exited-session children so external janitors aren't needed.
2. When utility workers die, recover them and the sessions they host. Currently the app keeps a dead session UI (or a dead window) until a full restart.

4. Minor: EBUSY on every launch

[error] [Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked,
copyfile '...\WindowsApps\Claude_1.22209.3.0_x64_...\app\resources\chrome-native-host.exe'
      -> '...\AppData\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe'

Impact: the actual complaint

We pay for the Max 20x plan. For weeks a meaningful share of that plan's usage has gone to having Claude diagnose and patch around Claude's own app instability, on top of daily lost sessions and forced restarts. In its current state on Windows, Desktop + Cowork is not delivering 20x-tier value. Please prioritize Windows Desktop stability. Happy to provide full scrubbed logs on request.