[BUG] CLI Crashes with posix_spawn EAGAIN Error Due to Recursive pgrep Calls

reproduction steps:

• have CC run a process that hangs
• double tap escape to interrupt (in vim mode)
• it gets into the issue.

I'll provide a test command

happens on a different terminal as well

Ghostty 1.1.2

Version
  - version: 1.1.2
  - channel: stable
Build Config
  - Zig version: 0.13.0
  - build mode : builtin.OptimizeMode.ReleaseFast
  - app runtime: apprt.Runtime.none
  - font engine: font.main.Backend.coretext
  - renderer   : renderer.Metal
  - libxev     : main.Backend.kqueue
 ```

This is (apparently) caused by installing proctools ps:

https://github.com/anthropics/claude-code/issues/4316#issuecomment-3188347086

I don't have access to my subscription to confirm at this time. If this is the case it helps to know this to either remove it or make sure proctools isn't available to CC, Thanks.
The issue should still stay open regardless IMO so that it's solved by CC

workaround for me:

brew uninstall proctools

I want to fix this issue as soon as posible.

I haven't proctools installed on my machine, and I get into this error

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

I don't have access to Claude code this moment to verify if it's still an issue but if you are still seeing it bump this to prevent auto-closure of the issue.

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

I have been experiencing this problem frequently today - in the middle of performing relatively trivial actions, Claude Code crashes with an infinite loop of error like this

EAGAIN: resource temporarily unavailable, posix_spawn '/opt/homebrew/bin/pgrep'
      path: "/opt/homebrew/bin/pgrep",
   syscall: "spawn pgrep",
     errno: -35,
 spawnargs: [ "-P", 60312 ],
      code: "EAGAIN"

      at spawn (node:child_process:667:35)
      at spawn (node:child_process:14:39)
      at <anonymous> (/$bunfs/root/claude:190:41503)
      at RoR (/$bunfs/root/claude:190:41996)
      at <anonymous> (/$bunfs/root/claude:190:42231)
      at forEach (1:11)
      at $ (/$bunfs/root/claude:190:42170)
      at emit (node:events:98:22)
      at #maybeClose (node:child_process:766:16)

❯ claude --version
2.0.76 (Claude Code)

Getting the same issue as well. I see a lot of zombie/defunct processes.

If there's one thing that can bring my $8,000 Mac Studio to its knees, it's being fork bombed by Claude.

Yes, this isn't a bug. Yes, the brew uninstall proctools workaround works. Apparently that's the random nonstandard open source dependency that's drinking your milkshake. But it's nasty enough problem you may want to consider taking steps to avoid it anyway.

I’ve also experienced similar issues. Numerous pgrep processes were generated, causing the system to become completely unresponsive.
The following is a reproduction screen. When monitoring the process after the query, multiple pgrep processes are generated as shown below and enter the ‘Resource temporarily unavailable (OS error 35)’ state.

Claude CLI version: 2.1.19 (Claude Code)
Operating System: macOS 26.2 (25C56)
Terminal: wezterm 20240203-110809-5046fc22 also kitty, alacritty, ghostty, iterm ...
Multiplexer: zellij 0.43.1
Shell: zsh 5.9 (arm-apple-darwin23.1.0)
<img width="2560" height="1410" alt="Image" src="https://github.com/user-attachments/assets/dac52466-f403-43f0-8516-095c66eec5b0" />

In case you're on Apple silicon (M1+) and you already tried brew uninstall proctools with no luck, check where pgrep is installed on your machine via which pgrep. Mine was installed in /usr/local/bin/pgrep despite being on Apple silicon (brew should install in /opt/homebrew for Apple silicon) 🤦. Turns out some packages were left over when I migrated from an older Intel Mac to M1. I removed orphaned Intel Homebrew files and then verified that which pgrep correctly returns /usr/bin/pgrep (the system-installed one). That fixed this issue for me.

In my environment, /opt/homebrew/bin/pgrep is used by default.
which -a pgrep
/opt/homebrew/bin/pgrep
/usr/bin/pgrep

---

~Observing the recurring situation, it appears to occur when modifying settings in $HOME/.claude/~
~Claude Code seems to be monitoring (watching) the $HOME/.claude directory in real-time, leading to a simultaneous sequence of file modification -> change detection -> configuration reload, potentially resulting in an infinite recursive state.~

In my environment, /opt/homebrew/bin/pgrep is used by default.

I'm not sure if you're still looking to fix the recursive pgrep issue (maybe you're just giving more context in your reply) so apologies if you knew this already but the fix for this issue is to REMOVE the pgrep you got via Homebrew by doing brew uninstall proctools and only have the one in /usr/bin/pgrep (the system-installed pgrep). You're currently using the Homebrew one despite having the system one.

@ShivanKaul Thanks.
Running brew uninstall proctools also removes /opt/homebrew/bin/pgrep.
which -a pgrep
/usr/bin/pgrep
In this state, the pgrep infinite spawning issue has disappeared.

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.