fix(grep): close subprocess stdin to prevent hook pipe leak (#897)

[celstnblacc]

Problem

When RTK is invoked via Claude Code's PreToolUse hook, the hook process keeps its stdin pipe open for the duration of the entire session. rg/grep subprocesses inherit this open pipe via the default Command stdin behaviour and block waiting for EOF — they never terminate.

On macOS with multiple concurrent grep calls (e.g. a long coding session with many search operations) memory accumulates unboundedly:

8 concurrent grep processes consumed ~514GB (RAM + swap) on a 96GB Mac Studio M2 Ultra, causing a macOS kernel panic. Single worst process: ~198GB.

Reported in #897.

Root Cause

Rust's std::process::Command inherits stdin from the parent process by default. When RTK is a subprocess of the hook runner, its stdin is the hook pipe. Children spawned by RTK inherit the same pipe. Since the hook pipe stays open for the whole session, the children never receive EOF and never exit.

Fix

Redirect subprocess stdin to /dev/null on both the rg primary path and the grep fallback:

rg_cmd.stdin(Stdio::null()); // decouples child from hook pipe

This is a 3-line change. Children now terminate immediately after completing their search, regardless of the parent hook pipe state.

Test plan

• cargo fmt --all — no formatting changes
• cargo clippy --all-targets — zero warnings
• cargo test --all — 1145 tests, 0 failures
• Manual: run an extended Claude Code session with RTK hook active, monitor with ps -eo pid,rss,comm | sort -k2 -rn to confirm grep processes terminate normally

Notes

• Backward compatible — Stdio::null() only affects stdin; stdout/stderr are unchanged
• Same fix should be applied anywhere else in the codebase that spawns subprocesses through the hook path (grep is the highest-frequency caller, hence the worst offender)

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 3 committers have signed the CLA.

✅ aeppling
❌ newblacc
❌ github-actions[bot]

---

newblacc seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[aeppling]

Hello @celstnblacc

Thanks for the contribution, could you sign the CLA please ?

[aeppling]

also this should target develop branch

[celstnblacc]

completed

[aeppling]

hey sorry just saw the version bump, this is not in PR scope and done automatically, please remove this and we should be ready to merge

[aeppling]

fixed

[aeppling]

CLA is not signed, you can sign by clicking the link https://cla-assistant.io/rtk-ai/rtk?pullRequest=945

then ready to merge

[pszymkowiak]

Thanks @celstnblacc — correct fix for #897. Note that PR #979 addresses the same issue with the same approach (Stdio::null() on both rg and grep fallback) without the version bump files. Whichever merges first supersedes the other.

[aeppling]

Closing with : #979

Thanks for contributing