fix: stop stderr leakage from git probes in workflow policies

[NiveditJain]

Summary

Workflow Stop policies (require-push-before-stop, require-pr-before-stop, require-ci-green-before-stop, etc.) run several git probes that are expected to sometimes fail — e.g., git log origin/<branch>..HEAD before the branch has been pushed, or git rev-parse --verify origin/<branch> to detect tracking. The policy code catches the exception cleanly, but Node's execFileSync / execSync default to stdio[2] = "inherit", so git's own stderr (fatal: Needed a single revision, fatal: ambiguous argument, etc.) leaked to the user's terminal even though the policy handled the failure correctly.

This surfaced as noise alongside every Stop-policy denial:

[bun ./bin/failproofai.mjs --hook Stop]: fatal: Needed a single revision
MANDATORY ACTION REQUIRED from failproofai (policy: require-push-before-stop): ...

Fix

Set stdio: ["pipe", "pipe", "pipe"] on every execFileSync/execSync call in src/hooks/builtin-policies.ts. stderr is now captured into the thrown error (and discarded) instead of bleeding through to the user. Applied uniformly across all 19 exec sites since the only supported "output" of these probes is the returned stdout — anything on stderr is noise.

Test plan

• npx tsc --noEmit passes
• Direct reproduction confirmed: a known-failing git log origin/no-such-ref..HEAD now returns silently with stdio: "pipe", vs. leaking fatal: ambiguous argument ... without it
• End-to-end: Stop hook output against a dirty tree no longer contains fatal: preamble; only the policy's own deny message is printed
• CI green

Generated with Claude Code

[coderabbitai]

Warning

Rate limit exceeded

@NiveditJain has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 22 minutes and 40 seconds before requesting another review.

Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 22 minutes and 40 seconds.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 015e4d9c-be1d-460c-a9be-824dffe08b6d

📥 Commits

Reviewing files that changed from the base of the PR and between a0c364a and 4203505.

📒 Files selected for processing (2)

• CHANGELOG.md
• src/hooks/builtin-policies.ts

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix-policy-stderr-leak

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}