claude agents: daemon and bg-spare processes spin at ~100% CPU when idle

Status Fixed / completed
Reported on v2.1.153
Maintainer reply ✓ Yes — bogini
Activity 7 comments · opened May 28, 2026 · closed May 28, 2026
💡 Likely answer: A maintainer (bogini, collaborator) responded on this thread — see the highlighted reply below.

Description

After running claude agents, the daemon and background worker processes spin at ~100% CPU per process even when there are no active tasks. The processes never exit on their own.

Steps to Reproduce

  1. Run claude agents in a terminal
  2. Let it sit idle (no tasks running)
  3. Open Activity Monitor (macOS) or top

Observed Behavior

Multiple claude.exe processes each consuming ~99–100% CPU:

claude agents          PID 1203  ~100% CPU
├── daemon run         PID 1212  ~100% CPU
│   ├── bg-pty-host    PID 1226  ~100% CPU
│   └── bg-pty-host    PID 1229  ~100% CPU
└── bg-spare           PID 1267  ~100% CPU

Total CPU usage: ~500% (5 cores pegged) while completely idle.

Expected Behavior

Idle processes should block on socket I/O and consume ~0% CPU.

Root Cause (suspected)

The Node.js child processes appear to be busy-waiting on Unix sockets instead of using blocking I/O or an event loop sleep. This looks like a missing await or an unintentional tight polling loop in the PTY host / spare process code.

Workaround

pkill -f 'claude agents'
pkill -f 'claude\.exe.*(daemon|bg-)'

Environment

  • Claude Code version: 2.1.153
  • OS: macOS 15 (Darwin 24.6.0)
  • Node.js: v22.22.3

View original on GitHub ↗

7 Comments

github-actions[bot] · 3 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/61800
  2. https://github.com/anthropics/claude-code/issues/62308

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

bogini collaborator · 3 months ago

Addressed by a merged fix. Please reopen with a fresh repro if you still see this on a current version.

linfeng16 · 3 months ago

▎ This issue was closed as fixed, but I'm still experiencing it on v2.1.154 (the latest version as of 2026-05-28).

▎ Environment:
▎ - Claude Code version: 2.1.154
▎ - OS: macOS Darwin 24.6.0

▎ Steps to reproduce:
▎ 1. Run claude agents in a terminal
▎ 2. Let it sit idle
▎ 3. Observe claude.exe bg-spare/bg-pty-host processes spinning at ~99% CPU each (3 processes × ~99% CPU)

▎ Observed:
▎ Three claude.exe processes (PIDs vary) consuming ~99.4%, 99.4%, 99.3% CPU while idle. Only solution is to kill them manually.

▎ Could this be reopened or tracked as a regression?

linfeng16 · 2 months ago

Still occurring on v2.1.161 (2026-06-03).

Environment:

  • Claude Code version: 2.1.161
  • OS: macOS Darwin 24.6.0

Observed: A --bg-spare process (PID 80814) ran from the previous evening with ~281 min CPU time, pinning one core at 100% CPU. The process survived daemon restart and was not cleaned up by claude-cleanup. Required kill -9 to terminate.

This appears to be a regression that has persisted from 153 → 154 → 161.

linfeng16 · 2 months ago

Could a maintainer please reopen this issue? The bug is still present in v2.1.161.

Full environment details:

  • Claude Code version: 2.1.161
  • macOS: 15.7.7 (Build 24G720)
  • Architecture: x86_64 (Intel)
  • Shell: fish

The --bg-spare orphan process from a previous session ran overnight (~281 min CPU time) pinning one core at 100% CPU. claude-cleanup did not remove it — only kill -9 worked.

linfeng16 · 2 months ago

Additional observation that may help narrow down the root cause:

The 100% CPU spin only occurs when the spare processes are idle (no active sessions). When a session is actively running — e.g. an agent task is in progress — the CPU usage drops to normal levels. As soon as the session goes idle again, the spin resumes.

This is consistent with a busy-wait loop in the spare process idle path: real I/O events from an active session drive the event loop normally, but when waiting for a new connection the process falls into a tight poll loop instead of blocking on the socket.

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