Desktop app crashes (no clean shutdown) under concurrent session-spawn load; same mechanism causes session-switch lag

Summary

The Claude desktop app (Windows) crashes without a clean shutdown when multiple sessions attempt to spawn/warm concurrently. The main process stalls on a ccd:spawn_query step for 13–24 seconds, and the app terminates within seconds of the stall clearing — no quit-cleanup log entry, no crash dialog, just a cold restart.

Two back-to-back occurrences were captured with matching signatures, ~7 minutes apart, suggesting the app's own post-crash session-recovery can retrigger the same condition (a possible crash loop).

Environment

• App version: 2.9939.2 (Windows, x64)
• Claude Code SDK/binary version: 2.1.281
• Node version: 24.21.0
• Platform: Windows 11 Pro

Evidence — Crash 1 (2026-09-26 15:28:05)

Immediately before the crash, three scheduled-task sessions hit a concurrency limit simultaneously while the interactive session was also active:

15:27:53 [info] [CCDScheduledTasks] Skipping dispatch for ken-daily-market-monitor: global_limit (active=3, limit=3)
15:27:53 [info] [CCDScheduledTasks] Skipping dispatch for jarvis-daily-brief: per_task_limit (active=1, limit=1)
15:27:53 [info] [CCDScheduledTasks] Skipping dispatch for jarvis-reply-processor: per_task_limit (active=1, limit=1)
15:27:57 [info] Received permission response for 75fe57a9-15cf-4ada-8050-b6354f533f91: once (tool: Bash)
15:28:05 [info] Starting app { appVersion: '2.9939.2', ... }

In the two minutes before that, the main process was already stalling repeatedly on session-spawn work:

15:27:13 [warn] [event-loop-stall] main process blocked for 5424ms (task ccd:spawn_query=5477ms, ...)
15:27:30 [warn] [event-loop-stall] main process blocked for 6462ms (task ccd:spawn_query=6494ms, ...)
15:27:52 [warn] [event-loop-stall] main process blocked for 13490ms (task ccd:spawn_query=13613ms, ...)
15:27:52 [warn] [file-index-worker] git ls-files failed; falling back to shallow BFS

Sustained memory in the 10 minutes prior: ~4.5–4.7GB tree RSS, 40–47 child processes (process-memory interval logs). No [quit-cleanup] previous quit block appears after the restart — the prior run ended without going through normal shutdown handlers.

Evidence — Crash 2 (2026-09-26 15:34:53, ~7 minutes after Crash 1)

Same signature. Two new sessions spawned within 14 seconds of each other, overlapping with two scheduled tasks confirming runs:

15:34:22 [info] [permissionMode] spawn local_704c9a3f-... mode=none ...
15:34:36 [info] [permissionMode] spawn local_e432238f-... mode=none ...
15:34:46 [warn] [event-loop-stall] main process blocked for 23835ms (task ccd:spawn_query=13728ms, ...)
15:34:46 [info] [remote-tools-device] pong timeout (1 consecutive) — resetting
15:34:46 [error] [sessions-bridge] Poll error, backing off: This operation was aborted
15:34:46 [warn] [file-index-worker] git ls-files failed; falling back to shallow BFS
15:34:46 [info] [git-worker] [gitDiff] Base ref not found: master in <repo>, falling back to HEAD
15:34:46 [info] [CCDScheduledTasks] Confirmed task run for: jarvis-daily-brief
15:34:46 [info] [CCDScheduledTasks] Confirmed task run for: jarvis-reply-processor
15:34:53 [info] Starting app { appVersion: '2.9939.2', ... }

Again, no quit-cleanup block after restart.

Reproduction pattern

Both crashes share:

1. Multiple sessions (interactive + scheduled-task) attempting to spawn/warm within the same ~15-second window
2. A ccd:spawn_query event-loop stall of 13+ seconds immediately preceding the crash
3. Termination within 7–8 seconds of the stall clearing
4. No clean shutdown record (quit-cleanup) logged for the terminated process — consistent with an ungraceful kill rather than a normal quit or a crash the app's own Crashpad handler caught (no Crashpad reports were generated for either event)

The ~7-minute gap between the two crashes, both triggered by concurrent session-spawn load, raises the possibility that post-crash recovery (resuming the prior session plus catching up on scheduled tasks interrupted by Crash 1) itself recreates the concurrent-spawn conditions that caused Crash 1 — i.e., a potential crash loop under this specific load pattern.

Impact

• Full, unrecoverable app crash (not just a hang) when several sessions/scheduled tasks spawn concurrently
• Separately, this same ccd:spawn_query stall mechanism (without reaching the crash threshold) is the direct cause of multi-second input lag when switching focus between sessions in the desktop app
• User has ~15 scheduled tasks configured with staggered but not fully isolated fire times, several of which run daily/every-2-hours, increasing the odds of overlapping spawns during normal use

What's already been ruled out

• Not caused by OneDrive Files-On-Demand / git hangs (a separate, previously-diagnosed issue) — this project's working directory is fully local, not synced via OneDrive
• Not caused by a stuck CoworkVMService (Windows service) — confirmed running normally, no startVM failed errors since a prior reboot
• Not caused by a specific scheduled task retry-looping — checked ken-daily-market-monitor's last 4 runs directly; all 4 succeeded, no failures or retries