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

Status Closed — not planned

Reported on v2.1.27

Maintainer reply None cached

Activity 6 comments · opened Jan 31, 2026 · closed Jan 31, 2026

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:

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

Scenario 2 — Concurrent sessions:

Start a Claude Code v2.1.27 session in one terminal
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:

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
High MCP server count (8) — the 29x API client creation burst correlates with total tool count across all servers
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

View original on GitHub ↗

6 Comments

github-actions[bot] · 8 months ago

Found 3 possible duplicate issues:

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

KyleWestendorf · 8 months ago

Also had same issue.

Summary

Multiple Claude Code processes became orphaned and stuck consuming 100% CPU when trying to run first message in 2.1.27, each for extended periods (30-40+ minutes), causing system slowdown.

Environment

Claude Code Version: 2.1.27

Operating System:

Distribution: Ubuntu 24.04.2 LTS (Noble)
Kernel: Linux 6.8.0-90-generic #91-Ubuntu SMP PREEMPT_DYNAMIC
Architecture: x86_64

Hardware:

CPU: AMD Ryzen 9 9950X 16-Core Processor (32 threads)
RAM: 60 GiB
Swap: 17 GiB

Runtime Environment:

Node.js: v20.19.2
npm: 11.3.0
Shell: /bin/bash
Terminal: xterm-256color

Issue Description

Observed Behavior:

5 Claude Code processes (PIDs: 6035, 6594, 6864, 9225, 11662) became

detached from their terminals

Each process consumed 100% of a single CPU core continuously
Processes had no controlling TTY (showed ? in ps output)
All processes were orphaned under systemd (PPID: 3537)
Processes started between 13:06-13:14, ran for 30-40+ minutes
Total system impact: ~18% CPU usage (5-6 cores out of 32), load average

reached 9.97

Process Details:
PID PPID TT STARTED %CPU TIME CMD
6035 3537 ? 13:06:25 100% 55:27.07 claude
6594 3537 ? 13:07:06 100% 54:46.51 claude
6864 3537 ? 13:07:28 100% 54:24.59 claude
9225 3537 ? 13:10:30 100% 51:23.42 claude
11662 3537 ? 13:14:16 100% 47:36.86 claude

Expected Behavior:

Claude processes should terminate when their controlling terminal session

ends

Processes should not consume 100% CPU indefinitely
No orphaned background processes

Steps to Reproduce

Resolution

Processes did not respond to SIGTERM (kill), required SIGKILL (kill -9) to
terminate.

antonsoo · 8 months ago

Having a very similar problem!
Running Claude-Code in WSL2 (Ubuntu 24.04).
Causing massive CPU use issues: I have a very powerful build and yet Claude-Code is causing my PC to almost crash.

Here's what Claude-Code told me about my issue and the options I have for a solution:

  ⚠️ Prevention Going Forward

  The bug is caused by the superpowers plugin writing duplicate UUIDs. Until Anthropic fixes this (issue #22245 is open), you have options:

  1. Keep using superpowers but periodically check for corrupted sessions:
  # Check for duplicate UUIDs (run this to detect problems early)
  for f in ~/.claude/projects/*/*.jsonl; do
    dups=$(grep '"saved_hook_context"' "$f" 2>/dev/null | jq -r '.uuid' | sort | uniq -d)
    if [ -n "$dups" ]; then
      echo "PROBLEM: $f has duplicate hook UUIDs"
    fi
  done
  2. Temporarily disable the superpowers plugin in ~/.claude/settings.json by setting "superpowers@claude-plugins-official": false (but you use it extensively, so option 1 is probably better)
  3. Wait for a fix - Issue #22245 was just filed today and is being actively looked at

ragtimelab · 8 months ago

Update: Root cause confirmed & workaround verified

Root Cause

As identified by @dicksontsai in #22198, the infinite loop is caused by transcript files containing saved_hook_context. When v2.1.27 processes messages from these transcripts, it enters an infinite loop consuming 100% CPU.

This affects any project using hooks (PreToolUse, PostToolUse, UserPromptSubmit), as hooks write saved_hook_context entries to .jsonl transcript files.

Verified Workaround

Delete all transcript files containing saved_hook_context:

``bash grep -rl "saved_hook_context" ~/.claude/projects/ | xargs rm -v``

Start a new Claude Code session — it works normally.

Confirmed on my environment

macOS 15.5 (Darwin 24.5.0), Intel x86_64, v2.1.27
After deleting 8 infected transcript files, v2.1.27 started normally with all MCP servers connected, keyboard input responsive, and CPU usage under 10%.

Cross-platform confirmation

@KyleWestendorf: Ubuntu 24.04.2 LTS, AMD Ryzen 9 9950X, 5 orphaned processes at 100% CPU
@antonsoo: Similar problem reported

Closing as duplicate of #22200 (assigned to @km-anthropic). Staying on v2.1.25 until the official patch lands.

ragtimelab · 8 months ago

Closing as duplicate of #22200. Workaround documented above.

github-actions[bot] · 8 months ago

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.

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

Description

Environment

Steps to Reproduce

Observed Behavior

Debug Log Pattern (consistent across 4 reproductions)

/doctor output from v2.1.25 (working session)

Expected Behavior

Hypothesis

Workaround

6 Comments

Update: Root cause confirmed & workaround verified

Root Cause

Verified Workaround

Confirmed on my environment

Cross-platform confirmation

Related Claude Code issues

Browse by topic

`/doctor` output from v2.1.25 (working session)