Claude Code consumes 100%+ CPU when idle in terminal

I have the same problem when I update cc to 2.x.

I have the same problem when I update cc to 2.x.

I just founded the reason.It was because an mcp service linked by claude code (python startup) was using a lot of cpu resources.

For me in a brand new Claude Code installation (Linux), CPU usage is near zero when I'm doing absolutely nothing, however it jumps to about 125% of a CPU core whenever it's trying to be more interactive, like when I start typing / and it shows suggestions. It will consume all that CPU indefinitely in that state. Even displaying the 3 panels of /help consumes that much until I ^C back to an empty prompt, where it drops back to zero. (Not to mention that my initial run consumed 5GB of RAM, but luckily stopping and restarting Claude Code brought that back down to a "low" 512 MB.)

Something fundamental is clearly broken in Claude Code. I wanted to migrate from Aider but I guess it would be premature. 🤔

Additional data: Tool execution triggers degradation

Environment: Linux 6.18.5-arch1-1, Claude Code 2.1.12, bundled Bun 1.2.x

Observation: Fresh sessions start healthy, but degrade after tool execution (not just idle time).

Measurements

| State | CPU (main thread) | Syscalls/2s | Notes |
|-------|-------------------|-------------|-------|
| Fresh session (idle) | 5.5% | 9 | Healthy, responsive UI |
| After tool use (docker ops) | 50-60% | 4200+ | Sluggish UI, busy-poll state |
| Previous long-running session | 12-15% | 9000 | Had been running since prior day |

Key finding

Restarting with --resume (same conversation context) returns to healthy state:

• Before restart: 15% CPU, ~4500 syscalls/sec
• After restart: 5% CPU, ~4.5 syscalls/sec

This suggests runtime state accumulation, not conversation size. Tool execution appears to trigger the busy-poll mode - possibly event listeners or timers that aren't cleaned up after tool completion.

Thread breakdown during degraded state

Main thread: 50% CPU
JITWorker:   2.3%
HeapHelper:  0.9% each (x7)

The degradation happened within minutes of running bash commands (docker operations), not hours of idle time.

I can trigger the CPU usage by doing some things with tasks + sub-agents pretty much every time. Tool use would make sense

Workaround: auto-kill orphaned processes

Until this is fixed, you can schedule a script to detect and kill orphaned claude processes (PPID=1, >50% CPU).

Script (~/.local/bin/kill-orphaned-claude.sh):

#!/bin/bash
pgrep -x claude | while read pid; do
  ppid=$(ps -o ppid= -p "$pid" 2>/dev/null | tr -d ' ')
  cpu=$(ps -o %cpu= -p "$pid" 2>/dev/null | tr -d ' ')
  if [ "$ppid" = "1" ] && [ "$(echo "$cpu > 50" | bc)" = "1" ]; then
    kill -9 "$pid" 2>/dev/null
  fi
done

Option 1 — macOS launchd agent (runs every 3 min):

<!-- ~/Library/LaunchAgents/com.user.kill-orphaned-claude.plist -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.user.kill-orphaned-claude</string>
    <key>ProgramArguments</key>
    <array>
        <string>/path/to/kill-orphaned-claude.sh</string>
    </array>
    <key>StartInterval</key>
    <integer>180</integer>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>

Load with: launchctl load ~/Library/LaunchAgents/com.user.kill-orphaned-claude.plist

Option 2 — cron job (Linux/macOS):

*/3 * * * * ~/.local/bin/kill-orphaned-claude.sh

Note: regular kill (SIGTERM) did not work for me on v2.1.27 — kill -9 (SIGKILL) was required.

Same issue rapsberry pi 4 with raspbian

Similar or same issue on Windows. Even when idle, waiting for user input consumes ~1 core. Typing something is very choppy. Typing while claude is working even worse.

Same problem with newest 2.1.29 on debian - once the task is done and claude is idling in terminal, it still eats 100% of one CPU core (some busy waiting?)

Here is an strace from my system:
strace.txt

It is not fixed up to stable 2.1.153