v2.1.27 hangs at 100% CPU after first response (v2.1.25 works)

Same!

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/22103
2. https://github.com/anthropics/claude-code/issues/22097
3. https://github.com/anthropics/claude-code/issues/22141

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

2.1.27 was working this morning but then stopped. I suspect it's an API issue.

Same!!!

+1. I think it's a P0 iisue

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.

Had to downgrade to 2.1.23 get a working version.

As mentioned in my (maybe) duplicate issue https://github.com/anthropics/claude-code/issues/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!)

$HOME/.local/share/claude/versions/2.1.22

Running claude with another profile in an older version (needs to be installed already!):

CLAUDE_CONFIG_DIR=$HOME/.claude-work $HOME/.local/share/claude/versions/2.1.22

v2.1.27 completely shut... uninstalled native, tried brew... no luck still.

workaround: https://github.com/anthropics/claude-code/issues/22103#issuecomment-3828430196

Downgrade to 2.1.23 indeed worked... for now!

I thought this was my laptop

I asked Gemini to investigate and this is what it came up with:

The actual issue identified was a race condition in the claude binary's execution flow,
specifically in how it spawns a secondary process for MCP (Model Context Protocol)
support.

Here is the breakdown:

1. The Trigger: When you run claude (interactive mode), it automatically tries to spawn

a second instance of itself with the flag --claude-in-chrome-mcp.

1. The Failure: The parent process and this child process were entering a livelock—a

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.

1. The Root Cause: The binary lacks sufficient internal synchronization (mutexes) to

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.

Additional Reproduction: Ghostty Terminal

Confirming this regression on Ghostty 1.2.3 with the same behavior.

Environment

• Claude Code: 2.1.27 (broken) → 2.1.25 (works)
• Terminal: Ghostty 1.2.3
• macOS: 26.1 (Build 25B78)
• Kernel: Darwin 25.1.0 arm64 (Mac Studio T6041)
• Shell: zsh
• TERM: xterm-256color

Behavior

• Claude Code starts normally in Ghostty
• First prompt submission: hangs indefinitely, becomes unresponsive
• Same version (2.1.27) works fine in Terminal.app

Workaround

ln -sf ~/.local/share/claude/versions/2.1.25 ~/.local/bin/claude

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.

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.