[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).

Start by reproducing the report with several session tabs and stdio MCP servers while sampling per-process Get-Process TotalProcessorTime at roughly 1.5-second intervals. Cross-reference %LOCALAPPDATA%\Claude\Logs\main.log, especially [event-loop-stall] entries, with the CPU spikes and compare the findings against issues #93121, #79999, and #92325. Done means the trigger and affected process are isolated or the CPU and event-loop behavior are explained and addressed.

Vom Indexierungsmodell aus dem Issue-Text verfasst.