You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(guardrails): narrow or retire block-hook-bypass now that shell file changes are checked #6689
#6674 step 2. block-hook-bypass.sh blocks shell file writes by command shape (cat >, echo >, python3 -c ... write), while node x.js and python3 x.py write freely. With check-bash-file-changes (step 1) running the Write/Edit content guards on every repository file a Bash or PowerShell command changed, the shape-based block covers mostly what the outcome check already sees.
Proposed
Narrow block-hook-bypass.sh to the cases check-bash-file-changes cannot see (a file outside the cwd's repository, a gitignored file, a write the snapshot misses), or retire it. Per the hook-precision convention, land the stay-quiet tests for each relaxed form first, failing against the current guard.
Thanks for the write-up. I understand this as a follow-up to #6674: once check-bash-file-changes runs the Write/Edit content guards against every file a Bash/PowerShell command touches, block-hook-bypass.sh's shape-based detection (cat >, echo >, etc.) becomes mostly redundant, and the proposal is to narrow it to the gaps the outcome check can't see (files outside the repo, gitignored files, missed writes) or retire it, with stay-quiet tests landing first per the hook-precision convention.
Scope and next step look clear; this is explicitly blocked on the #6674 (step 1) pull request merging first, so it isn't actionable yet on its own. I didn't find an existing duplicate — #5668 and the other block-hook-bypass issues listed are related but cover different gaps.
Closing as not planned. The owner decided (2026-10-10, option A) to drop the narrowing and keep block-hook-bypass as on main after four security review rounds found new bypasses; PR #6708 closed on that decision.
Activity
github-actions commentedon Oct 9, 2026
Thanks for the write-up. I understand this as a follow-up to #6674: once
check-bash-file-changesruns the Write/Edit content guards against every file a Bash/PowerShell command touches,block-hook-bypass.sh's shape-based detection (cat >,echo >, etc.) becomes mostly redundant, and the proposal is to narrow it to the gaps the outcome check can't see (files outside the repo, gitignored files, missed writes) or retire it, with stay-quiet tests landing first per the hook-precision convention.Scope and next step look clear; this is explicitly blocked on the #6674 (step 1) pull request merging first, so it isn't actionable yet on its own. I didn't find an existing duplicate — #5668 and the other block-hook-bypass issues listed are related but cover different gaps.
Automated triage. A maintainer reviews it.
kyle-sexton commentedon Oct 18, 2026
This was generated by AI during backlog shaping.
Closing as not planned. The owner decided (2026-10-10, option A) to drop the narrowing and keep block-hook-bypass as on main after four security review rounds found new bypasses; PR #6708 closed on that decision.
Evidence:
The owner approved this in an attended backlog-shaping session on 2026-10-17.