[BUG] Windows Desktop: main session process CPU spikes to 600–900%+ for ~2s during response streaming, coinciding with event-loop stalls up to 17s

Preflight Checklist

• [x] I have searched existing issues. Closest matches are related-but-distinct and separated below (#93121, #79999, #92325).
• [x] This is a single bug report.
• [x] I am using the latest version of Claude Code.

What's Wrong?

Environment

• App: Claude desktop app 1.52386.3
• Bundled Claude Code runtime: 2.1.266
• OS: Windows 10 Home, build 10.0.19045, x64
• Hardware: AMD Ryzen Threadripper 1950X (16 cores / 32 threads, 3.4GHz), 64GB RAM
• Is this a regression?: I don't know — this is the first time I measured it directly; no earlier-version baseline.
• Platform: Anthropic API (consumer subscription, not Bedrock/Vertex)

Symptoms

While multiple session tabs are open (each with its own claude.exe main process, no --type= flag — i.e. not the Electron shell/renderer/GPU processes, but the per-session process that hosts an active conversation), individual session processes intermittently spike to 600–900%+ CPU for about 2 seconds, then drop back to single digits. Measured with 1.5s-interval TotalProcessorTime deltas across all claude.exe PIDs:

| PID role | Duration | CPU% (32-core box) |
|---|---|---|
| session process A | ~2s | 869% |
| session process B | ~2s | 688% |
| session process C | ~2s | 648% |

All three sessions had several stdio MCP servers attached as children (e.g. a chat-platform client, a DB client, a mail client — each spawns its own child process per session, so process count scales with MCP count × open sessions).

Cross-referencing main.log for the same wall-clock window shows the main process's own [event-loop-stall] instrumentation firing repeatedly in the same window, tagged with task sdk:stream-delta-flush:

19:43:17  blocked for 17105ms [likely sleep: duration_heuristic] (task sdk:stream-delta-flush=1ms, ...)
19:44:39  blocked for 6413ms  (task LocalSessions.isWorkingTreeDirty=0ms, ...)
19:44:55  blocked for 6608ms  [likely sleep: duration_heuristic] (task sdk:stream-delta-flush=0ms, ...)
19:45:13  blocked for 4854ms  (task sdk:stream-delta-flush=0ms, ...)
19:45:46  blocked for 4695ms  (task LocalSessions.cancelQueuedMessage=0ms, ...)

Over a dozen sdk:stream-delta-flush-tagged stalls occurred in an 8-minute window, several exceeding 1 second and one reaching 17 seconds.

Caveat on the task tag: per #92325's own analysis of this exact log format, the task X=Nms annotation records only the tagged task's own execution time (here, 0–1ms), not what caused the surrounding multi-second block — #92325 found many stalls tagged task none and traced the real cause, via an external watchdog plus WinDbg thread dumps, to UI-thread message-pump spinning and synchronous filesystem calls unrelated to any streaming task. I am not claiming sdk:stream-delta-flush itself is the blocking code — only that these severe multi-core CPU bursts and the event-loop stalls tagged near sdk:stream-delta-flush occur in the same narrow window. The causal mechanism inside claude.exe is unknown to me; I'm reporting the correlation because #92325 didn't have a CPU-magnitude measurement to connect to its stall data.

What Should Happen?

Whatever runs during response streaming should not saturate 6–9 CPU cores per session for ~2 seconds, and should not block the main process's event loop for multiple seconds (up to 17s observed in this window). With several sessions open, these per-session bursts appear to compound into system-wide CPU pressure.

Steps to Reproduce

1. Open several session tabs, each with 2+ stdio MCP servers attached.
2. Have 2-3 of them actively generating/streaming a response concurrently.
3. Sample Get-Process TotalProcessorTime deltas (or equivalent) per claude.exe PID at ~1.5s resolution while this is happening.
4. Cross-reference %LOCALAPPDATA%\Claude\Logs\main.log for [event-loop-stall] entries in the same window.

This was observed once via live monitoring (not yet isolated to a minimal repro — the CPU sampling and the log cross-reference are the evidence, not a single deterministic trigger).

Related

• #93121 (Electron main process pins ~1 core / freezes UI during agent activity, ~105–155 CPU-sec/6s): same general "streaming load blocks the main process" class. This report's measurements are roughly 5–8x larger in magnitude (600–900%+ vs ~105–155%) but does not establish the same root cause — see caveat above.
• #79999 (renderer process runaway with many open sessions, 150–245% sustained): different process role (--type=renderer) and a sustained pattern, vs. this report's short (~2s) bursts on the main per-session process. Possibly related, possibly independent.
• #92325 (stalls over 5s mis-tagged as sleep and dropped from the app's own counters, and — via UI-thread stack sampling — traced mainly to message-pump spinning / synchronous filesystem calls, not to any streaming task): shares the exact log format and sdk:stream-delta-flush tag with this report, and its own data already shows that tag's own duration is near-zero even next to multi-second blocked for totals — so the tag alone isn't evidence of causation. This report adds a data point #92325 didn't have: direct multi-core CPU measurement (600–900%+, roughly 6–9 of 32 logical cores) on the per-session process during the same class of stall window, which is much larger than #92325's single-UI-thread sampling (max ~85% of one core). Whether the two symptoms share a root cause is unresolved — flagging the correlation for maintainers who can see the actual call stacks.

Terminal/Shell

Claude Desktop app (not terminal-launched).