[BUG] Desktop main process blocks ~2.2s on every session open/switch — bundled `claude.exe` takes ~2.45s just to print `--version`

Summary

On Windows, every session open / session switch in Claude Desktop freezes the main process for ~2.2 seconds. During the freeze the window paints white, then recovers on its own. Repeating it (opening/switching several sessions in a row) accumulates into AppHangTransient and the app eventually exits.

The cause appears to be that the desktop app spawns the bundled Claude Code CLI (claude.exe, ~253 MB) on session lifecycle events, and that binary needs ~2.45 s just to initialize — measured with the lightest possible workload.

Environment

| | |
| --- | --- |
| OS | Windows 10 Pro for Workstations, 10.0.19045 |
| CPU | Intel Core i7-10700K @ 3.80GHz (8C/16T) |
| RAM | 64 GB |
| Install type | MSIX / Store package (Claude_1.24012.9.0_x64__pzs8sxrjxfjjc) |
| Desktop app | 1.24012.9.0 |
| CCD | 2.1.219 (also reproduced on 2.1.217) |

Minimal reproduction

Anyone can check in one line — run the bundled CLI with the cheapest possible argument:

%LOCALAPPDATA%\Packages\Claude_<id>\LocalCache\Roaming\Claude\claude-code\<version>\claude.exe --version

Result on this machine (3 consecutive runs, warm):

2456 ms
2457 ms
2449 ms

~2.45 s, with 8 ms of variance across runs. Binary size: 253 MB (2.1.219), 247 MB (2.1.217).

For comparison on the same machine: cmd /c exit = 33 ms, pwsh -NoProfile -c exit = 234 ms, bash -lc exit = 762 ms.

Log evidence

logs/main.log reports the stalls, and attributes them to session-lifecycle tasks whose own duration is ~0 ms — i.e. the block is inside something they call, not in the task itself:

[warn] [event-loop-stall] main process blocked for 2268ms (task Resources.setFocusedCwd=1ms, total 1, cumulative 2268ms, rss 243MB)
[warn] [event-loop-stall] main process blocked for 2159ms (task LocalSessions.start=0ms, total 2, cumulative 4427ms, rss 256MB)
[warn] [event-loop-stall] main process blocked for 2113ms (task webrequest:before-send-headers=0ms, total 4, cumulative 8611ms, rss 258MB)
[warn] [event-loop-stall] main process blocked for 2306ms (task Resources.setFocusedCwd=0ms, total 14, cumulative 31263ms, rss 331MB)

346 event-loop-stall entries in the current log. In one ~2-minute window of normal session switching: 16 stalls, 35.7 s cumulative blocked time.

The line immediately preceding the stalls is consistently:

[info] LocalSessions.checkGhAvailable: cwd=Z:\...

The measured CLI startup time (~2.45 s) matches the observed stall durations (2.18–2.36 s) closely enough that the spawn looks like the blocking operation.

Ruled out (each tested, not assumed)

| Hypothesis | How it was ruled out |
| --- | --- |
| GPU / compositing | Launched with --disable-gpu via Invoke-CommandInDesktopPackage — no change |
| Proxy / WPAD auto-detect | Launched with --no-proxy-server — 16 stalls still logged afterwards |
| Antivirus | Real-time protection disabled for 1 hour — no change; also the 8 ms run-to-run variance rules out scanning |
| Disk speed | %TEMP% is on a secondary HDD; benchmarked at 56 ms for 200 small-file writes (C: = 51 ms) |
| %TEMP% location | Re-ran the CLI with TEMP/TMP pointed at C: — 2437/2456 ms, no difference |
| Disk spin-down | Kept the drive continuously active — no change |
| SMB / network drives | Unmapped all three network drives — no change |
| IME | User dictates via voice input; no typing involved, still reproduces |
| MCP servers | claude_desktop_config.json has no MCP servers configured |
| PATH lookup cost | All 47 PATH entries measured at 0–15 ms; where gh = 113 ms |
| Shell profile | No PowerShell profile exists on this machine |
| Version regression | 2.1.217 = 2386 ms, 2.1.219 = 2440 ms — both slow |

Impact

• Every session switch freezes the UI for ~2 s, rendering a white window during the freeze.
• Windows Event Log records AppHangTransient for claude.exe (6 occurrences within 7 minutes during normal use).
• Opening/interacting with several sessions in a row eventually terminates the app.
• Because this is an MSIX/Store install, the usual Electron workarounds (adding launch flags, compatibility settings) are not reachable without Invoke-CommandInDesktopPackage.

Startup is the worst window

Immediately after launch (session restore + file indexing), the stalls come back to back. Real log excerpt, three stalls within 5 seconds:

03:32:40 [warn] [event-loop-stall] main process blocked for 2484ms (task Resources.setFocusedCwd=0ms, total 3, cumulative 6846ms, rss 350MB)
03:32:42 [warn] [event-loop-stall] main process blocked for 2386ms (task worker:file-index:reply=1ms, total 4, cumulative 9232ms, rss 382MB)
03:32:45 [warn] [event-loop-stall] main process blocked for 2399ms (task webrequest:before-send-headers=0ms, total 5, cumulative 11631ms, rss 398MB)

The app is unresponsive for roughly 2.4 s out of every 2.5 s during this window. Clicking during startup queues more work and the app is terminated shortly after — the log shows a re-initialization 28 seconds after the previous one.

Note: Crashpad produces no dump. This is a hang being terminated, not a crash, which is presumably why it leaves no crash telemetry.

With 10 open sessions, the startup window is long enough to be unusable.

Expected

Either the CLI spawn should not block the main process's event loop, or the bundled CLI's ~2.45 s cold start should be reduced. On an 8-core i7-10700K with 64 GB RAM, 2.45 s to print a version string suggests the startup cost is in the binary itself rather than the host machine.

Note

Several existing reports describe a permanent white screen (#68364, #51143, #49551). This one is different and may be a separate defect: the window recovers by itself after ~2 s, and the freeze is reproducible on demand by switching sessions.