[Bug] pgrep fork bomb causing session hang with repeated command execution
Status Fixed / completed
Reported on v2.1.114
Maintainer reply None cached
Activity 4 comments · opened Apr 19, 2026 · closed Apr 23, 2026
Bug Description
There is a consistent bug I have had for monthes of claude code. It consistently fork bombs my session with the command 'pgrep', I do not know the conditions which trigger this, it may have to do with sub-shells, but how hard would it be, to just check if pgrep has been run more than 20 times repeatedly, or something to that effect. This persistent bug has survived through many iterations of claude code, and I am disappointed it hasn't been addressed.
Environment Info
- Platform: darwin
- Terminal: iTerm.app
- Version: 2.1.114
- Feedback ID: 9c409506-8023-43d3-a003-faadcd6aa9b8
Errors
Complete crash of my iTerm server, no ability to spawn new shells until I force-kill in Activity Monitor.
It exhausts my user process limit, and claude becomes a ghost process I need to force quit. A fork bomb effectively.
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
A repeated
pgreploop that exhausts the user process limit is well beyond ordinary tool flakiness. Once it reaches the point of crashing the terminal server and preventing new shells from spawning, this becomes a session-level safety failure.The especially concerning part is that the failure mode is mechanically repetitive and bounded enough that the product should be able to detect it. If the same probe command is being launched dozens of times in a tight window, there should be a circuit breaker before it escalates into a fork-bomb-like condition.
So there are really two issues here:
pgreploop at allEven without fully fixing the trigger immediately, a defensive limit would materially reduce harm. For example: if the same command or near-identical process tree is spawned repeatedly above some threshold, pause further launches, surface an explicit warning, and require user confirmation before continuing.
This connects to a broader theme in recent reports: hidden background activity continues past the point users expect, and the system lacks strong boundaries when automation starts to self-amplify. A good agent runtime should degrade safely under repetition, not take down the user shell environment.
@0xbrainkid Right, so when will anyone get around to at least a basic fail-safe? I have witnessed this problem for over a year.
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.