Repository navigation
Claude Code enters unrecoverable CPU spin after MCP tool response #36729
Description
Bug Description
Claude Code enters an unrecoverable 100% CPU spin after receiving a normal MCP tool response. The process becomes completely unresponsive — Ctrl-C, Esc, and all input are ignored. Only kill -9 terminates it. Zombie child processes are left unreaped.
Environment
- Claude Code version: Latest (installed via
claude updateon 2026-03-19) - OS: macOS (Apple Silicon, Darwin 25.3.0)
- Shell: zsh
- Model: claude-opus-4-6 (1M context)
Reproduction
- Start a Claude Code session with a custom MCP server providing tools
- During conversation, invoke an MCP tool that returns a well-formed JSON response (~2758 bytes, ~4 objects)
- The MCP tool completes successfully and returns data to Claude Code
- Claude Code enters CPU spin instead of generating the assistant response
Specific trigger observed: report_proposals(filter="read") MCP call returned 2758 chars of valid JSON (4 proposal objects). The tool result was received successfully but the runtime never generated a response.
Observed Behavior
- Duration: ~11.5 hours of sustained 100% CPU before manual kill (started 12:47 AM, killed 12:09 PM EDT on 2026-03-20)
- Process state:
R+(running, foreground) — pure CPU spin, not I/O blocked - Input: Ctrl-C and Esc completely non-responsive
- Session ID:
6b7a00f4-8d44-4adc-8e22-495502c64cbe - Zombie children: Two child processes (node workers) were never reaped after parent was killed
Expected Behavior
Claude Code should either:
- Generate a response after receiving the MCP tool result, or
- Time out and surface an error to the user, or
- Remain responsive to Ctrl-C/Esc for graceful termination
Additional Context
- The MCP response was well-formed JSON, not truncated or malformed
- This is not the first hang observed — Agent subagent calls have also hung with no timeout/recovery mechanism
- No custom hooks or scripts were executing at the time — the hang occurred in the Claude Code runtime itself during response generation
- The session transcript (JSONL) shows the MCP tool result was the last entry before the hang
Impact
- 11.5 hours of wasted compute
- Required manual process investigation and kill -9
- Zombie processes left on system requiring cleanup
- No built-in detection, timeout, or recovery mechanism exists in Claude Code
Reacted by Dmitry Avdonkin
Activity
github-actions commentedon Mar 20, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
synman commentedon Mar 20, 2026
mention #18532
#34565
#36469
synman commentedon Mar 20, 2026
Dupe Assessment — These Are Different Bugs
I've analyzed all three tagged potential duplicates. They share the symptom (hang/freeze) but have different root causes:
#18532 — Closest match (same class)
100% CPU infinite loop, R+ state, kill -9 required, macOS ARM64. This is the same class of bug — the runtime enters a CPU spin and becomes unresponsive. My issue adds a new reproduction path: the hang occurs after a normal MCP tool response is fully received (proven by JSONL transcript forensics).
#34565 — Different bug (tool never returns)
A
WebFetchcall that never returns — the hang is waiting for I/O. In my case, the MCP tool did return (2758 bytes of valid JSON written to transcript). The CPU spin started during response generation, not during tool execution. Different failure point entirely.#36469 — Different bug (oversized response)
Hang triggered by a large Figma MCP response that exceeds processable size. My trigger was a 2758-byte response (~4 JSON objects) — trivially small. The response content is not the issue.
Forensic Evidence
The JSONL session transcript (
6b7a00f4) proves the exact failure sequence:report_proposals(filter="read")was issuedThe hang is in the response generation phase of the Claude Code runtime — after receiving valid input, before producing output. This is distinct from both "tool never returns" (#34565) and "oversized response" (#36469).
Context payload at time of hang
This is well within the 1M context window. The payload size may be a contributing factor but the response itself was small and well-formed.
Request
Please don't auto-close this as a duplicate. It provides the most precise diagnostic data of any issue in this class:
This narrows the search space for the underlying runtime bug significantly.
Cross-reference: Detailed forensics also posted on #18532 (the oldest open issue in this class).
fortunexbt commentedon Apr 15, 2026
@synman this is one of the nastiest unattended-runtime failure modes I have seen — the MCP tool response was valid, the session received it, and then Claude just spins at 100% CPU for 11+ hours with zero recovery path. No timeout, no heartbeat, no Ctrl-C escape. Only kill -9.
That is exactly the class of failure that makes headless agent automation untrustworthy. The tool did its job; the runtime poisoned itself afterward.
Are you more blocked by not having a programmable timeout that kills a stuck session before it burns a full day of compute, or by not having runtime health signals that would let an operator detect the spin automatically and intervene?
I am building PicoMUTX around exactly this operator-control gap and happy to compare notes if useful.
synman commentedon Apr 15, 2026
Fortunately this was just pure cpu spin on a single core so it didn't consume tokens / etc
oviron commentedon Apr 21, 2026
Reproducing #36729 on v2.1.114 — 100% CPU spin after parallel sub-agent MCP responses
Adding a fresh reproduction of this bug. Identical symptoms, three simultaneous occurrences on the same machine in 48h.
Environment
--dangerously-skip-permissionsTrigger
User-invoked custom skill
/research, which spawned onegeneral-purposesub-agent. Sub-agent issued 4 parallelmcp__tavily__tavily_searchcalls and enteredthinking with high effort. At ~2m 2s / ~2.3k tokens of the thinking phase, main Claude Code locked up.Observations
R+state, 100% CPU, for 12h 46m before manual killCtrl-C,Esccompletely unresponsive; terminal couldn't even be scrolledThree earlier hangs from the same machine
Pattern is not a one-off. At the time of investigation three older hung sessions were still live:
Combined ~68 hours of wasted compute. All four had identical `R+` / 100% CPU / zombie-children signature. Only `kill -9` terminated them.
Hypothesis
Sub-agent exits cleanly (hence zombie in parent), writes its final message to the pipe, but main-thread parser/harmonizer enters an infinite loop on the response. Matches the harmonizing-step hang in #21399 and the JSON-serialization hang in #4580.
Trigger combination: parallel MCP tool calls inside a sub-agent + extended thinking (`high effort`). Removing parallelism (sequential MCP calls) appears to avoid it.
Would be helpful
Happy to attach a `sample` trace from the live hung process if it helps.
nestorcolt commentedon Apr 29, 2026
same problem here even opus 46 - 47 anbd the latest cc 2.1.123 (Claude Code)
github-actions commentedon May 30, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Jul 31, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.