Bash tool: grep→ugrep shim children not killed on timeout; runaway memory (100+ GB) on long-line files

Environment

• Claude Code 2.1.204 / 2.1.205, macOS (Darwin 25.5.0), zsh
• Model: claude-fable-5

Summary

The Bash tool injects a grep shell function that re-executes the claude binary as embedded ugrep (ARGV0=ugrep $CLAUDE_CODE_EXECPATH -G --ignore-files --hidden -I --exclude-dir=.git ...). Two problems compound:

1. Orphaned children on timeout. When a Bash tool call times out, the spawned ugrep process is not killed. It keeps running (and allocating) indefinitely, invisible to the session that spawned it.
2. Pathological memory on single-line files. On minified HTML (~300-600 KB, one long line) with -o and bounded-repetition patterns like [^>]{0,90}(foo|bar)[^<]{0,90}, embedded ugrep's RSS grows unbounded — observed 8 GB RSS in 45 seconds on a 263 KB file, VSZ ~440 GB per process.

A background session that repeatedly grepped fetched HTML in /tmp accumulated 6+ orphaned ugrep processes (0.5–8 GB RSS each), pushing Activity Monitor's App Memory for the terminal's tree past 126 GB and the machine into heavy swap. The session itself never saw an error — each call just timed out and it retried, spawning another orphan.

Repro sketch

1. Save any large minified single-line HTML file (e.g. a marketing page) to /tmp/page.html.
2. In a Claude Code session, have the Bash tool run: grep -oiE '[^>]{0,90}(alpha|beta|gamma)[^<]{0,90}' /tmp/page.html
3. Watch RSS of the resulting ugrep process grow multi-GB; let the tool call hit its 2-minute timeout.
4. ps aux | grep ugrep → the process survives the timeout and keeps growing.

Expected

• Bash tool timeout should kill the whole process group (SIGTERM then SIGKILL), not just abandon the foreground wait.
• Ideally the ugrep shim should bound worst-case memory (or fall back to system grep) on files with extremely long lines.