v2.1.27 hangs at 100% CPU after first response (v2.1.25 works) #22158
Description
Bug Report: v2.1.27 hangs at 100% CPU after first response
Environment
- Claude Code Version: 2.1.27
- Working Version: 2.1.25
- OS: macOS Darwin 25.2.0 (Apple Silicon)
- Model: Opus 4.5
Description
After starting a Claude Code session and receiving the first response, the CLI hangs at 100% CPU. The spinner shows but no further responses are possible. This happens consistently on v2.1.27 but NOT on v2.1.25.
Steps to Reproduce
- Start Claude Code v2.1.27:
claude - Enter any prompt (e.g., "hello")
- Receive first response successfully
- Enter second prompt
- CLI hangs at 100% CPU, spinner shows "Billowing..." or similar but never completes
Troubleshooting Attempted
- Disabled all plugins (27 plugins) - still hangs
- Disabled all hooks (PreToolUse, PostToolUse, UserPromptSubmit, Stop) - still hangs
- Disabled all MCP servers - still hangs
- Disabled statusLine command - still hangs
- Cleared debug files and file-history - still hangs
- Vacuumed sessions.db - still hangs
- Fresh session after /exit - still hangs
Workaround
Running v2.1.25 directly works without issues:
~/.local/share/claude/versions/2.1.25Process State When Hung
claude 100.0% CPU, ~500MB-2GB memory, R+ state (running)
Multiple Claude sessions can accumulate, all spinning at 100% CPU.
Binary Size Difference
- 2.1.25: 182,288,624 bytes
- 2.1.27: 179,283,440 bytes (3MB smaller)
Expected Behavior
CLI should remain responsive after first response and process subsequent prompts normally.
Actual Behavior
CLI spins at 100% CPU and becomes unresponsive after first successful response.
Reacted by Adel Zaalouk, evgeny-gozentry, Fredrik Ekman, Nick Foscarini, Adam Akhlaq, Rodolfo, bimbolimbo, Marcel Bich, Kevin Mok, Joel Moss and 17 more
Activity
zanetworker commentedon Jan 31, 2026
Same!
github-actions commentedon Jan 31, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
codemile commentedon Jan 31, 2026
2.1.27 was working this morning but then stopped. I suspect it's an API issue.
ocean-neo commentedon Jan 31, 2026
Same!!!
wang-silas commentedon Jan 31, 2026
+1. I think it's a P0 iisue
bimbolimbo commentedon Jan 31, 2026
similar issue, but i am on linux. I've noticed it depends on the directory. Home directory fine, other directories super slow, can't even run /doctor in claude TUI. When the fan starts churning when running /doctor, then you know somethings is off.
Kevin-Mok commentedon Jan 31, 2026
Had to downgrade to 2.1.23 get a working version.
Marcel-Bich commentedon Jan 31, 2026
As mentioned in my (maybe) duplicate issue #22172 this occurs on multiple sessions too (somehow I can work in 1 session only but if I try to start another everything freezes but the first session.)
=> The only confirmed workaround for me is downgrading to v2.1.22 like this:
Running claude in older version (needs to be installed already!)
Running claude with another profile in an older version (needs to be installed already!):
SharadKumar commentedon Jan 31, 2026
v2.1.27 completely shut... uninstalled native, tried brew... no luck still.
codemile commentedon Jan 31, 2026
workaround: #22103 (comment)
SharadKumar commentedon Jan 31, 2026
Downgrade to 2.1.23 indeed worked... for now!
bhaskoro-muthohar commentedon Jan 31, 2026
I thought this was my laptop
jmclaughlin724 commentedon Jan 31, 2026
I asked Gemini to investigate and this is what it came up with:
The actual issue identified was a race condition in the
claudebinary's execution flow,specifically in how it spawns a secondary process for MCP (Model Context Protocol)
support.
Here is the breakdown:
a second instance of itself with the flag --claude-in-chrome-mcp.
state where both were consuming 100% CPU waiting on each other or competing for the
same resource (file scanners in the deployment-log-checker skill), without making
progress.
prevent this collision when the file system or skill state causes a delay.
We resolved this by:
Wrapping the binary with a script (claude_shim.sh) that implements an external mutex.
This ensures that if an MCP process is already running or being spawned, a second one
cannot start, effectively forcing sequential behavior and preventing the resource
collision.
richardwhiteii commentedon Jan 31, 2026
Additional Reproduction: Ghostty Terminal
Confirming this regression on Ghostty 1.2.3 with the same behavior.
Environment
Behavior
Workaround
This suggests the regression may involve terminal handling that differs between Ghostty and Terminal.app. Ghostty uses a different input/PTY implementation which may be exposing the underlying issue more readily.
github-actions commentedon Feb 8, 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.