[BUG] My Mac OS crashes due to claude running `find /` command (reboot multiple times a day)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

After investigations and multiple OS kernel crashes, it seems that the root cause is CLAUDE running commands like:

eval 'find /Users/admin/.project /tmp -name "*.log" 2>/dev/null | head;
        find / -name "*.log" -path "*project*" 2>/dev/null | head'

See the find / which seems to be the culprit

Here's my agent summary:

--------------

## Summary

Claude Code injects a zsh shell function named find into the Bash tool's
environment. The function re-execs the claude binary with argv[0]=bfs and
-regextype findutils-default. When invoked this way, the binary runs in
breadth-first traversal mode and holds an open directory FD per pending
frontier directory.

On a tree with high branching at one level (e.g. node_modules with ~25k
subdirs alongside git worktrees), a single find invocation accumulates
~65,000 DIR file descriptors — close to kern.maxfilesperproc (122,880) and
a meaningful fraction of kern.maxfiles (245,760). Multiple concurrent
invocations or other processes reaching for FDs at the same time can saturate
kern.maxfiles and crash the box.

## Environment

• macOS (Darwin 25.3.0)
• Claude Code 2.1.119
• Repository with node_modules, multiple git worktrees, Postgres data dirs

## Evidence

A standalone FD monitor running lsof every 30s caught the same fingerprint
three times in two days. The 2026-04-26 instance preceded a hard system
reboot; the 2026-04-27 instances were near-misses (peak ~31% of kern.maxfiles).

Each leaking process shows:

• ps: bfs -regextype findutils-default <repo-root> -name '*.ts' …
• lsof type breakdown: 65,533 DIR / 4 REG / 1 CHR
• lsof txt mapping: /Users/<me>/.local/share/claude/versions/2.1.119

The txt mapping confirms the running executable is the Claude binary
itself; the bfs in ps is argv[0], set by exec -a bfs in the injected
shell function:

```sh
find () {
local _cc_bin="${CLAUDE_CODE_EXECPATH:-}"
[[ -x $_cc_bin ]] || _cc_bin=$(command -v claude 2>/dev/null)
if [[ ! -x $_cc_bin ]]; then
command find "$@"
return
fi
if [[ -n $ZSH_VERSION ]]; then
ARGV0=bfs "$_cc_bin" -regextype findutils-default "$@"
elif [[ "$OSTYPE" == "msys" || "$OSTYPE" == "cygwin" || "$OSTYPE" == "win32" ]]; then
ARGV0=bfs "$_cc_bin" -regextype findutils-default "$@"
elif [[ $BASHPID != $$ ]]; then
exec -a bfs "$_cc_bin" -regextype findutils-default "$@"
else
( exec -a bfs "$_cc_bin" -regextype findutils-default "$@" )
fi
}

(Sourced from ~/.claude/shell-snapshots/snapshot-zsh-*.sh per session.)

Reproduction

In any repo with a populated node_modules:

find . -name '*.ts'

Watch FDs for the spawned process:

lsof -p <pid> | wc -l

You should see tens of thousands of DIR entries piling up before the
traversal completes.

Impact

• macOS hard reboot on 2026-04-26 (same fingerprint as the captured incidents)
• Two near-misses on 2026-04-27 with the system reachable but degraded
• Any unrelated processes running on the host (gateway, postgres, editors)

start failing open(2) once kern.maxfiles saturates

Suggested fixes

1. Bound the FD count inside the bundled bfs implementation — use a

path-based queue and lazy openat/fts(3)-style depth-first walk rather
than holding an open FD per frontier directory.

1. Auto-prune well-known noise dirs (node_modules, .git, dense

worktree/cache trees) when running via the shim.

1. Provide an opt-out env var (e.g. CLAUDE_CODE_DISABLE_FIND_SHIM=1) so

users can fall back to the system find while a real fix lands.

1. Make the rewrite visible to the permission system so users can author

Bash(find:*) rules that actually catch the dangerous invocations.

Copy from the code fence above — that's the raw markdown ready to paste into a GitHub
issue.

What Should Happen?

My Operating system should not crashes

Error Messages/Logs

Steps to Reproduce

In any repo with a populated node_modules:

find . -name '*.ts'

Watch FDs for the spawned process:

lsof -p <pid> | wc -l

You should see tens of thousands of DIR entries piling up before the
traversal completes.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.119

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_