Multiple processes span with 100 %CPU usage in activity monitor

!Image

not just macos - this is my linux server

oh, and I'm not using VSCode - so maybe not specific to that either

<img width="1346" height="457" alt="Image" src="https://github.com/user-attachments/assets/10262b9c-3c8b-4182-9423-54566ad3aaed" />

All of these claude instances are idle yet churning CPU

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/18532
2. https://github.com/anthropics/claude-code/issues/17219
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

Related to the mentioned issues, but slightly different. My VS Code claude became completely irresponsive even after disabling and enabling it again. And the ghost processes spawn on startup, maybe caused by VS Code, but every session started in terminal spawns 2 10%CPU usage processes

I think this is not a dupe and was introduced with v2.1.29 or v2.1.28. I just updated today from v2.1.27 and saw the CPU surge.

● Bash(sudo strace -p 1326707 -c 2>&1 &
      STRACE_PID=$!…)
  ⎿  Error: Exit code 143
     Command timed out after 15s
     strace: Process 1326707 attached
     strace: Process 1326707 detached
     % time     seconds  usecs/call     calls    errors syscall
     ------ ----------- ----------- --------- --------- ----------------
      43.16    0.073961           8      8559           munmap
      30.77    0.052731           6      8568           mmap
      13.09    0.022426          14      1498        18 futex
       4.27    0.007311          36       202           sched_yield
     … +27 lines (ctrl+o to see all)

● There it is. In 5 seconds: 8,559 munmap + 8,568 mmap calls — that's ~3,400 mmap/munmap cycles per second. The process is in a tight memory allocation/deallocation
  loop. Plus 1,498 futex calls and 202 sched_yields.

  This is garbage collection thrashing — the Bun/V8 runtime is continuously allocating and freeing memory even while idle. That's the bug. It's not polling for input; it's GC churning. The HeapHelper threads we saw earlier in the per-thread view confirm this — V8's heap management is running hot.

  This is definitely a Claude Code bug worth reporting if it isn't already covered by that issue.

I don't know what this means but it is the result of a claude code self investigation.

Agreed, seeing the same and still high mem usage on 2.1.29, I don't think the issue is as fixed as they claimed.

Strangely, on subsequent runs mem usage seems back under control. Strange was definitely high on first run of .29.

Will keep monitoring.

Dowgraded with claude install 2.1.27 and cpu usage is back to normal.

Edit: never mind idle claudes started eating cpu again after a while, even on 2.1.27

<img width="1381" height="272" alt="Image" src="https://github.com/user-attachments/assets/c711889a-bc1a-4eed-b4ee-9cab0c3c4396" />

<img width="664" height="265" alt="Image" src="https://github.com/user-attachments/assets/9ec26002-e00e-4719-8fd9-874ffd2e5a01" />

I just ran claude install 2.1.27 and the terminal usage was working fine. I opened up VS Code with the claude extension on, and it once again activated the two expensive processes and is still thinking the answer to the prompt "what version of claude code are you" (I wanted to make sure it was also using 2.1.27, won't get an answer since I'm killing this process now)

Edit: I realized in the Extension page itself it says it uses 2.1.29, so it once again points to being an issue with that version or with the VS Code extension. I'll wait for a next version to update before using the extension again

Oh I was on latest, so I guess claude upgraded itself back to 2.1.29 and that's why the cpu bug came back.
Switched to stable in my settings.

● Update(.claude/settings.json)
  ⎿  Added 1 line, removed 1 line
      1  {
      2 -  "autoUpdatesChannel": "latest"
      2 +  "autoUpdatesChannel": "stable"
      3  }

Possible version mismatch trigger

I experienced similar symptoms today (startup freeze, orphaned processes at 100% CPU ignoring SIGTERM).

Timeline in my case:

• VS Code extension auto-updated to 2.1.27 at 09:01
• CLI was already at 2.1.29
• Problems started around 15:58 (startup freezes, ~20 failed session attempts)
• VS Code extension updated to 2.1.29 at 23:38
• After both were on 2.1.29, CLI sessions started working normally

Not certain this was the root cause, but the version mismatch (CLI ahead at 2.1.29, VS Code behind at 2.1.27) correlates with the problem window. Once they matched, the issue resolved.

Worth investigating whether shared state in ~/.claude/ has version-dependent schemas that might cause conflicts.

Environment: macOS Tahoe 26 (Apple Silicon), Node 24.9.0

Cross-reference: /clear as immediate workaround

I've posted detailed diagnostic data in #22509 showing the same issue on macOS M3 Max with 10 concurrent idle sessions consuming 667% CPU total.

Key finding: Running /clear in a session immediately drops CPU from ~98% to 0% and reduces memory from 2GB to 160MB. This strongly suggests the root cause is accumulated session state triggering continuous GC activity, not a polling/event-loop issue.

The workaround for users with multiple long-running sessions:

1. Run /clear in each high-CPU session
2. Or terminate and restart sessions that have been running > 24h

See #22509 for full environment details, thread analysis, and session age vs CPU correlation data.

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

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.