v2.1.27 regression: Event loop stuck (CPU 90%+ spin) on startup when stale lock exists or another session is running

Description

Claude Code v2.1.27 becomes unresponsive on startup under a specific environment. The event loop appears to get stuck, causing CPU usage to spike to 87-120% and making keyboard input completely unresponsive. This does not occur with v2.1.25 under the same conditions.

Note: This may be environment-specific rather than a general regression, as no other reports have been found for v2.1.27.

Environment

• OS: macOS Sequoia (Darwin 24.5.0)
• Architecture: x86_64 (Intel Core i5-9600K) — NOT Apple Silicon
• Working version: v2.1.25 (188,585,664 bytes)
• Broken version: v2.1.27 (185,580,480 bytes — ~3MB smaller, possible build change)
• Install method: native
• MCP servers: 8 total (4 global: time, fetch, context7, sequential-thinking + 3 project via .mcp.json + 1 built-in: claude-in-chrome)
• Hooks: 3 (PreToolUse, PostToolUse, UserPromptSubmit in .claude/settings.json)
• Project: Has .mcp.json, .claude/settings.json with hooks, .claude/settings.local.json, skills directory

Steps to Reproduce

On Intel Mac with the environment above:

Scenario 1 — Stale lock:

1. Start a Claude Code v2.1.27 session
2. Force-kill it (close terminal, kill -9, etc.) so the PID lock is not released
3. Start a new v2.1.27 session → stuck (CPU 90%+, no keyboard input)

Scenario 2 — Concurrent sessions:

1. Start a Claude Code v2.1.27 session in one terminal
2. Start another v2.1.27 session in a different terminal/IDE → second session stuck

Control tests:

• Same scenarios with v2.1.25 → works normally (CPU ~2%, keyboard responsive)
• v2.1.25 session running alongside v2.1.27 session → v2.1.25 works fine
• v2.1.27 runs fine as a single session with no stale locks (pkill -9 -x claude first)

Observed Behavior

• Main thread enters R (Running) state at 87-120% CPU
• UI renders initially (prompt appears, MCP servers connect) but keyboard input is completely ignored
• Debug log stops writing ~4 seconds after startup while CPU continues spinning
• Process must be kill -9'd (cannot /exit due to no keyboard input)
• Killed process leaves orphan/stale state that blocks subsequent sessions

Debug Log Pattern (consistent across 4 reproductions)

All MCP servers connect successfully, then log stops:

[DEBUG] MCP server "time": Successfully connected (2-3s)
[DEBUG] MCP server "fetch": Successfully connected (2-3s)
# ... all servers connect ...
[DEBUG] AutoUpdaterWrapper: Installation type: native
[DEBUG] Found 2.1.27 at ~/.local/bin/claude, skipping install
# === LOG STOPS HERE === CPU remains at 90%+

In one reproduction with 6 MCP servers, 29 identical [API:request] Creating client + [API:auth] OAuth token check entries appeared at the exact same millisecond timestamp right before the freeze, suggesting a tight synchronous loop over all MCP tools.

/doctor output from v2.1.25 (working session)

Version Locks
└ 2.1.25: PID 26526 (running)

Expected Behavior

Session should start normally regardless of stale locks or concurrent sessions, as v2.1.25 does.

Hypothesis

Possible factors that may contribute to this issue:

1. Intel x86_64 architecture — v2.1.27 binary is ~3MB smaller than v2.1.25, suggesting a build/optimization change that may behave differently on Intel
2. High MCP server count (8) — the 29x API client creation burst correlates with total tool count across all servers
3. Lock handling change — v2.1.27 may have changed how PID version locks interact with concurrent/stale processes

Workaround

Downgrade to v2.1.25:

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