You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] ccusage statusline causes infinite process spawning loop leading to 100% CPU usage #459
The ccusage statusline command causes an infinite process spawning loop when used with Claude Code's statusline hooks, leading to complete system overload.
Environment
ccusage version: 15.9.1
Runtime: Bun v1.2.19
OS: Ubuntu 24.04.2 LTS
Claude Code: v1.0.72
Server: Hetzner CX22 (2 vCPU, 4GB RAM)
Configuration
{
"statusLine": {
"type": "command",
"command": "bun x ccusage statusline",
"padding": 0
}
}
Issue DetailsWhat happens:1. Claude Code statusline hook executes bun x ccusage statusline2. ccusage processes hang/don't terminate properly3. Claude Code detects timeout and spawns new process4. Process accumulation continues indefinitely5. System becomes unresponsive due to resource exhaustionResource Impact:- CPU Usage: 300%+ (30+ parallel processes each consuming 8-15% CPU)- Memory: 3+ GB consumption- Load Average: 21.73 (normal <2.0)- Active Processes: 34+ simultaneous node ccusage statusline instancesReproduction:1. Add statusline config to ~/.claude/settings.json2. Use Claude Code for 2-3 minutes3. Check ps aux | grep ccusage - multiple hanging processes4. Monitor with htop - CPU usage climbs to 100%Expected Behavior- Single ccusage process per statusline call- Process terminates after returning output- Normal CPU/memory usageActual Behavior- Multiple processes spawn continuously- Processes don't terminate properly- System overload requiring manual interventionWorkaroundTemporarily disable statusline:
{
"$schema": "https://json.schemastore.org/claude-code-settings.json",
"model": "sonnet"
}
Additional Context- Feature works correctly when called manually: bun x ccusage statusline --help- Issue appears to be specific to statusline hook integration- Same problem reported by other users in Reddit thread- Beta feature - possibly related to stdin handling or process lifecycle managementLogs$ ps aux | grep ccusageclaude-+ 3152617 8.8 4.5 11525868 178220 pts/2 Rl+ ccusage statuslineclaude-+ 3152645 8.5 3.9 11508688 154340 pts/2 Rl+ ccusage statuslineclaude-+ 3152678 8.6 3.9 11489148 153540 pts/2 Rl+ ccusage statusline
[... 30+ more processes]
Thanks for the amazing tool! This is the only issue preventing production usage of the statusline feature.
I'm using the npx -y version and not seeing this. I just somewhat wonder what's causing this. Hopefully the project owner knows, but maybe try some different ideas to help better understand the issue. I can't think that NPX vs BUN would make a difference, but it's possible. You could also try running the BUN command independently just to make sure there's no obvious issue.
I can reproduce this issue as well.
The ccusage processes are indeed accumulating as shown in the top screenshot.
My hypothesis and investigation:
I suspected this might be a timing mismatch between ccusage execution speed and statusline request frequency, so I decided to measure both sides:
My measurements:
ccusage statusline execution takes ~10 seconds in my environment
Statusline requests occur much more frequently - about half of the requests come within 1-second intervals when measured over ~100 turn converstation
This timing gap causes new processes to spawn faster than existing ones can complete
Analysis:
Based on my measurements, I think the root cause might be that Claude Code's statusline hook spawns new ccusage processes before previous ones finish executing. Since ccusage takes significantly longer to execute than the statusline refresh rate, processes could accumulate and consume CPU resources.
This could explain the behavior described in the issue - the processes might not be terminating properly because new ones keep getting spawned before the previous ones complete their work.
Reacted by Alex Stewart, Thushan Fernando and ursisterbtw
@9wick Well-written report. Eyballing the CLI's behavior while this issue is active, I can visibly see the refresh rate (rapid blinking), which subsequently spawn new node processes
I'm still having this issue, and its making CC Usage and status line edits unusable at this point - as it locks up the system still. @ursisterbtw - Mac OS Dev Beta here.
The statusline process-spawning issue has been addressed in the current implementation with per-session semaphore/cache handling, active updater process detection, and refresh interval support. Remaining concerns around semaphore placement and multi-user tmpdir behavior are better tracked in #755 against the current code, so I am closing this as completed.
Activity
spotshare-nick commentedon Aug 11, 2025
I'm using the
npx -yversion and not seeing this. I just somewhat wonder what's causing this. Hopefully the project owner knows, but maybe try some different ideas to help better understand the issue. I can't think that NPX vs BUN would make a difference, but it's possible. You could also try running the BUN command independently just to make sure there's no obvious issue.thushan commentedon Aug 12, 2025
can repro with bun also - things went a bit bunanas:
macOS & PopOS with latest CCode. As mentioned in the bug report, can only repro this issue with statusline, on its own it's okay.
tommyruin commentedon Aug 12, 2025
Issue: Memory leak causing 20+ Node.js processes when used as Claude
Code status line
Environment:
Problem:
shell execution loops
150MB-600MB each)
global Claude Code settings
Root Cause:
system
like:
/c/Users/tommy/.claude/shell-snapshots/snapshot-bash-[id].sh
Impact:
Workaround:
"%USERPROFILE%.claude\shell-snapshots"
Recommendation:
ccusage may need better process cleanup or compatibility testing with
Claude Code's shell management system.
ursisterbtw commentedon Aug 12, 2025
I've had the exact same issue on Ubuntu
9wick commentedon Aug 16, 2025
I can reproduce this issue as well.
The ccusage processes are indeed accumulating as shown in the top screenshot.
My hypothesis and investigation:
I suspected this might be a timing mismatch between ccusage execution speed and statusline request frequency, so I decided to measure both sides:
My measurements:
ccusage statusline execution takes ~10 seconds in my environment

Statusline requests occur much more frequently - about half of the requests come within 1-second intervals when measured over ~100 turn converstation

This timing gap causes new processes to spawn faster than existing ones can complete
Analysis:
Based on my measurements, I think the root cause might be that Claude Code's statusline hook spawns new ccusage processes before previous ones finish executing. Since ccusage takes significantly longer to execute than the statusline refresh rate, processes could accumulate and consume CPU resources.
This could explain the behavior described in the issue - the processes might not be terminating properly because new ones keep getting spawned before the previous ones complete their work.
alexstewartja commentedon Aug 16, 2025
@9wick Well-written report. Eyballing the CLI's behavior while this issue is active, I can visibly see the refresh rate (rapid blinking), which subsequently spawn new node processes
ryoppippi commentedon Aug 17, 2025
published https://github.com/ryoppippi/ccusage/releases/tag/v15.9.8
added semaphore for exploding process in statusline
please try it out
alexstewartja commentedon Aug 17, 2025
@ryoppippi Eager to try this, as
statuslinehad become unusable. Will report back!ryoppippi commentedon Aug 17, 2025
really so it is become worth...?
thank you for try it out as always!!
ryoppippi commentedon Aug 18, 2025
oh use v15.9.9 instead!!
ryoppippi commentedon Aug 18, 2025
so it depends on users' machine power, os, network or so it is hard to reproduce it.
in my env it works so well.
so i need your feedback!!
ursisterbtw commentedon Aug 19, 2025
the update fixed the process spawning issue for me on ubuntu 25.04 👍
DevVig commentedon Aug 20, 2025
I'm still having this issue, and its making CC Usage and status line edits unusable at this point - as it locks up the system still. @ursisterbtw - Mac OS Dev Beta here.
fix: prevent infinite ccusage process spawning with file-based locking
fix: prevent infinite ccusage process spawning with file-based locking
fix: prevent infinite ccusage process spawning with file-based locking
b3nw commentedon Aug 21, 2025
Same issue here
AhmadShbeeb commentedon Aug 22, 2025
same here using hyprland on arch Kernel: 6.12.43-1-lts , zsh 5.9
❯ ccusage --version 16.1.1 ❯ claude --version 1.0.88 (Claude Code)ryoppippi commentedon Aug 22, 2025
So configure refreshinterval
ryoppippi commentedon Aug 22, 2025
I mean it depends on your machine. If your machine is faster enough this issue doesn't happen. But you can add refreshinterval option to manage it
Fix memory leaks: use global better-ccusage, add timeouts, reduce pol…
ryoppippi commentedon May 17, 2026
The statusline process-spawning issue has been addressed in the current implementation with per-session semaphore/cache handling, active updater process detection, and refresh interval support. Remaining concerns around semaphore placement and multi-user tmpdir behavior are better tracked in #755 against the current code, so I am closing this as completed.