Comment by Vic Moreno on "pkill -f cat quits every app on a Mac, and coding agents keep running it"

The trap is that -f matches the whole command line, and every app path on a Mac contains /Applications/, which contains "cat". Running pgrep -fl with the same pattern first shows the blast radius before anything dies. Did any of the three issues get a fix, or is it still on the user to block pkill -f in a hook?

Thanks. All three are still open as of today (anthropics/claude-code #100684, #107867 and #90070), so for now it is still on the user. The hook in the post is the smallest version of that: it refuses pkill -f when pgrep -fl with the same pattern finds a process inside a .app bundle, and tells the agent to kill by PID instead. bulkhead 0.3.5 does the same check and also refuses patterns that reach 8 or more processes outside the calling session.

Refusing on a match inside a .app bundle is the right test, much tighter than a plain pkill block. Kill by PID also leaves a clear trail in the transcript. Does the 8-process threshold in bulkhead count child processes of the calling session, or only its direct children?

The whole tree. bulkhead walks down from the calling session's Claude Code process and treats every descendant as that session's own: the shell, a dev server started from it, and the server's workers, at any depth. Those are left out of the count. Everything else the pattern matches counts toward the 8, including other sessions' processes and unrelated programs. A child is only accepted if it started after its parent, so a reused PID on Windows does not pull an unrelated process into the tree, and on Linux a server that outlived its shell is still matched to its session through CLAUDE_PID in its environment.

Search Hashnode