100% CPU usage while idle awaiting user input

Status Closed — not planned
Maintainer reply None cached
Activity 12 comments · opened Jan 27, 2026 · closed Mar 5, 2026

Description

Claude CLI consumes 100%+ CPU while idle waiting for user input at the prompt. The process should be sleeping/blocked on stdin read, but instead is actively running.

System Information

  • Platform: Raspberry Pi 5 (ARM64)
  • OS: Linux (Debian-based)
  • Claude CLI Version: Latest from npm

Diagnostic Output

top output

PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
8175 jferraro  20   0   71.6g 959712  52480 R 114.0   5.9  22:28 claude

Note: Process is in R (running) state, not S (sleeping).

strace analysis

Running strace -p <pid> -f reveals three issues:

Issue 1: Busy-polling /proc stats

[pid  8175] pread64(10, "18762362 239712 13120 13620 0 16"..., 256, 0) = 41
[pid  8175] pread64(10, "18762362 239712 13120 13620 0 16"..., 256, 0) = 41
[pid  8175] pread64(10, "18762362 239712 13120 13620 0 16"..., 256, 0) = 41

The main thread is reading /proc/self/stat (process statistics) in a tight loop with no sleep between reads. This appears to be resource monitoring code (likely for status bar memory display) without any rate limiting.

Issue 2: Spinlock contention

[pid  8550] sched_yield()
[pid  8551] sched_yield()
[pid  8552] sched_yield()

Three worker threads are in tight sched_yield() loops - classic spinlock starvation pattern. They yield CPU but immediately retry, burning cycles.

Issue 3: 16ms timer (60 Hz)

timerfd_settime(7, ..., {it_value={tv_sec=0, tv_nsec=16000000}}, ...)

A 60Hz timer is running (reasonable for UI), but combined with busy polling creates excessive load.

Expected Behavior

When idle at the input prompt, the process should:

  1. Block on stdin read (sleeping state)
  2. Poll resource stats at most once per second, not continuously
  3. Worker threads should be sleeping on condition variables, not spinning

Impact

  • Drains battery on laptops
  • Causes thermal throttling on low-power devices (Pi)
  • Wastes significant CPU resources
  • Makes the system less responsive for other tasks

Suggested Fix

Replace the busy-poll resource monitoring with a timer-based approach (e.g., poll /proc/self/stat once per second). Review worker thread synchronization to use proper blocking primitives instead of spinlocks.

View original on GitHub ↗

12 Comments

CodeYozh · 7 months ago

Additional system information:

$ echo $TERM
xterm-256color

$ echo $SHELL
/bin/bash

$ claude --version
2.1.20 (Claude Code)
github-actions[bot] · 7 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/17142
  2. https://github.com/anthropics/claude-code/issues/19393
  3. https://github.com/anthropics/claude-code/issues/17148

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

infactai · 7 months ago

100% CPU is a bug. 100% :)

AlexanderBartash · 7 months ago

Guys, this is ridiculous. Terminal app uses more CPU than IntelliJ. Please fix this.

mikiobraun · 7 months ago

Was reported on 2.1.20, we're now on 2.1.27 and it's still happening. Please have a look!

Smana · 7 months ago

Yes several issues regarding performances: memory leak and this cpu usage.

alessandrolattao · 7 months ago

Same here! It makes my CPU throttle down and the system becomes unresponsive.

clemlesne · 6 months ago

Can confirm issue on macOS. 10 instances, all with a conversation of about ~20 messages each. All idle, no use, no tasks, no agents. Instances are using from 20% to 100% CPU on a MacBook Pro M1 Max, consuming nearly all the CPU.

ksacry-ft · 6 months ago

Here is an strace from my system:

strace.txt

mikiobraun · 6 months ago

I did some digging with Claude and gdb, and it thinks it's related to a bug in bun, and apparently that has been fixed, so there might be some hope: https://github.com/oven-sh/bun/issues/25430

github-actions[bot] · 5 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

github-actions[bot] · 5 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.