Grep tool: spawn 'rg' ENOENT on macOS v2.1.96 (regression of #15026)

Bug description

The Grep tool fails with ENOENT: no such file or directory, posix_spawn 'rg' on every invocation in Claude Code v2.1.96 on macOS. This is the same class of bug as #15026 / #43336, but manifesting on rg (the Grep tool) rather than pgrep.

Environment

• Claude Code version: 2.1.96
• Install method: VS Code extension (~/.vscode/extensions/anthropic.claude-code-2.1.96-darwin-arm64/resources/native-binary/claude)
• OS: macOS Darwin 25.4.0 (Apple Silicon, arm64)
• Shell: zsh
• System ripgrep: /opt/homebrew/bin/rg v15.1.0 (Homebrew, Mach-O arm64, executable, runs standalone fine)

Error output

Every Grep tool invocation returns:

ENOENT: no such file or directory, posix_spawn 'rg'

Investigation

1. rg is installed and executable at /opt/homebrew/bin/rg:

``
$ /opt/homebrew/bin/rg --version
ripgrep 15.1.0
$ file /opt/homebrew/bin/rg
/opt/homebrew/bin/rg: Mach-O 64-bit executable arm64
``

1. /opt/homebrew/bin IS in the Claude Code process environment per ps eww:

``
$ ps eww -p <claude-pid> | tr ' ' '\n' | grep '^PATH='
PATH=/Users/.../.antigravity/.../bin:/Users/.../.local/bin:/opt/homebrew/bin:/opt/homebrew/sbin:...
``

The first several PATH entries include /opt/homebrew/bin, yet the spawn still fails with ENOENT.

1. The CC binary bundles ripgrep statically — strings on the native binary reveals ripgrep's code (rg::search, RIPGREP_CONFIG_PATH, full help text) AND a literal cmd=\"rg\" spawn site. So the single-file binary contains ripgrep internally but still tries to spawn rg as an external command for the Grep tool, then fails.

1. The Bash tool works fine — it resolves rg via its interactive shell snapshot. Only the native Grep tool's spawn path fails. This mirrors #43336's finding that Bun's spawn() uses a different PATH resolution than the shell-snapshot-backed Bash tool.

Related issues

• #15026 — canonical spawn pgrep ENOENT on macOS, closed stale
• #43336 — v2.1.91 regression of the above on pgrep, closed as duplicate of #15026. Root cause from that report: "Bun's subprocess spawning uses a restricted PATH that doesn't include /usr/bin"
• #42068 — bundled vendor/ripgrep/arm64-darwin/rg losing execute permission (different root cause, npm install only)
• #20733 — stale vendored rg path after native installer migration, closed as duplicate

The pattern: Bun's spawn() in the CC single-file binary on macOS uses a restricted/cached PATH that doesn't agree with the parent process's PATH. Fixed once for pgrep, regressed; now manifesting on rg. Each instance is auto-closed as a duplicate of a stale parent, and the underlying Bun-spawn-PATH issue isn't resolved. Filing a fresh report rather than commenting on the locked duplicates.

Reproduction steps

1. Install Claude Code v2.1.96 via the VS Code extension on macOS (Apple Silicon)
2. Install ripgrep via Homebrew (brew install ripgrep) — present at /opt/homebrew/bin/rg
3. Start a Claude Code session
4. Invoke the Grep tool (e.g., search for any pattern)
5. Observe ENOENT: no such file or directory, posix_spawn 'rg'

Expected behaviour

Any of:

1. Use the statically-bundled ripgrep inside the CC binary (it is already linked in)
2. Resolve rg via an absolute path using a full PATH walk at spawn time
3. Fall back gracefully to the bundled copy when external rg can't be resolved

Workaround

Use the Bash tool with explicit /opt/homebrew/bin/rg. Works, but adds friction — compound-command permission prompts, no structured output, no glob/type filters.