Repository navigation
Closed as not planned
Closed as not planned
Copy link
Labels
area:corebugSomething isn't workingSomething isn't workinghas reproHas detailed reproduction stepsHas detailed reproduction stepsperf:memoryplatform:linuxIssue specifically occurs on LinuxIssue specifically occurs on LinuxstaleIssue is inactiveIssue is inactive
Description
Summary
Claude Code consumes 27-33% of a CPU core when idle (waiting for user input), caused by a busy-wait loop pattern visible in syscall traces.
Environment
- OS: Fedora 43 (Linux 6.18.3)
- CPU: Intel Core i7-14700 (20 cores)
- Claude Code version: Latest (installed via
~/.local/bin/claude)
Observed Behavior
Multiple Claude Code instances running:
| PID | CPU % | Status |
|---|---|---|
| 71457, 72589, 89061, 89978 | 0.3-0.4% | Truly idle (from previous day) |
| 614750 | 33.2% | "Active" but waiting for input |
| 946540 | 27.8% | "Active" but waiting for input |
The "active" instances are just sitting at a prompt, not processing anything.
Syscall Analysis
5-second strace on the 33% CPU process:
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
49.68 0.046981 7 5980 sched_yield
33.58 0.031758 1 21884 165 futex
6.08 0.005754 1150 5 wait4
5.46 0.005159 3 1293 epoll_pwait2
1.52 0.001439 0 5222 clock_gettime
1.48 0.001402 0 2450 statx
0.73 0.000687 0 1078 madvise
...
------ ----------- ----------- --------- --------- ----------------
100.00 0.094562 2 41221 1134 total
41,221 syscalls in 5 seconds (~8,200/sec) for an idle process.
Analysis
The syscall pattern indicates:
sched_yieldspam (5,980 calls) - Classic busy-wait: yielding CPU but immediately reschedulingfutexcontention (21,884 calls) - Heavy thread lock contentionclock_gettime(5,222 calls) - Constant time pollingstatx(2,450 calls) - Frequent file stat checks (file watcher?)
This is busy-polling behavior - the process yields to be "nice" but immediately wakes up again instead of properly blocking on I/O.
Expected Behavior
Idle CPU usage should be <1% (similar to the 0.3-0.4% seen in truly idle instances from the previous day).
Impact
- Battery drain on laptops
- Unnecessary heat/power consumption on desktops
- Wasted CPU cycles that could be used for compilation or other tasks
Reproduction
- Start
claudein a terminal - Let it sit idle at the prompt
- Observe CPU usage in
top/htopor KDE System Monitor - Run
strace -p <pid> -cfor 5 seconds to see syscall pattern
Reacted by igor and ksacry-ft
Metadata
Metadata
Assignees
Labels
area:corebugSomething isn't workingSomething isn't workinghas reproHas detailed reproduction stepsHas detailed reproduction stepsperf:memoryplatform:linuxIssue specifically occurs on LinuxIssue specifically occurs on LinuxstaleIssue is inactiveIssue is inactive
Activity
github-actions commentedon Jan 9, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
ElliotCallender commentedon Jan 23, 2026
Hi! Claude and I wrote a patch for this until Anthropic fixes the root issue.
cruppertautomation-ai commentedon Jan 31, 2026
Additional Data Point: Native Linux, Different Pattern, Root Cause Identified
Environment
Key Finding: This is a Different Variant
Your issue reports ~8,200 syscalls/sec from futex/sched_yield busy-wait. I'm seeing a different pattern:
CPU is burned in userspace, not syscall overhead.
Root Cause Identified: timerfd Firing Rate
Direct measurement via
strace -e read -cover 3 seconds on two instances:30x difference in timer activity.
The internal
timerfd(fd 7) controls the event loop poll interval:epoll_pwait2timeout = 1-16ms (60fps animation speed)epoll_pwait2timeout = 100ms (proper idle)Hypothesis
Claude Code sets a timerfd at ~30-60Hz for UI refresh (spinner, cursor, animation). When the session becomes idle, this timer should relax to 1Hz or stop. But sometimes it doesn't.
This explains:
stracecan "fix" it = ptrace attach interrupts event loop, allows timer recalculationSchrödinger's Bug
Notably, attaching
straceto debug the issue caused one stuck instance to recover (timer relaxed from 30Hz to 1Hz). The act of observation changed the behavior.Recommendation
Check for timers/intervals set for UI animations that don't get cleared or slowed when idle. The poll interval should relax to 100ms+ when truly idle.
igor-nav commentedon Feb 3, 2026
v2.1.29 on WSL2/Linux 6.6.87. Fresh session, no tools running, 47% CPU at idle. 12% battery drain in 5 minutes on a laptop. This makes Claude Code nearly unusable for untethered work.
ksacry-ft commentedon Feb 3, 2026
Here is an strace from my system:
strace.txt
github-actions commentedon Mar 5, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Mar 12, 2026
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.