guardrails: hook-disable paths block-no-verify does not see (git alias, Set-Item env:HUSKY/LEFTHOOK)

[kyle-sexton]

Problem

A bypass review of #4817 found commands that skip commit hooks and pass block-no-verify on current main, with no opt-in token set:

• git config alias.c 'commit -n'; git c -m x: an alias defined in the same command hides -n.
• Set-Item env:HUSKY 0; git commit -m x, Set-Item env:LEFTHOOK 0; git commit -m x, si env:LEFTHOOK 0; ...: hook managers disabled through PowerShell env assignment. (Main already blocks [Environment]::SetEnvironmentVariable('LEFTHOOK','0') and bash LEFTHOOK=0 git commit.)

Expected

These block like --no-verify: a same-command git config alias.* whose value contains a no-verify flag, and PowerShell env assignment (Set-Item/si/$env: = ...) of HUSKY, LEFTHOOK or other hook-manager disable variables the guard already knows for bash.

Acceptance criteria

• block-no-verify.test.sh cases for each command above, blocked.
• The PowerShell env-assignment forms share the list of hook-disable variables the bash path uses.

Related

• guardrails: read-only git inside {} blocked by two guards, with irrelevant commit guidance, Bash-lane advice, and no narrow lever #4235, fix(guardrails): PowerShell read-only git grouping + ps-computed-positional (#4235) #4817

[kyle-sexton]

This was generated by AI during triage.

Agent Brief

Type: Bug
Summary: block-no-verify blocks PowerShell env assignment of hook-manager disable variables and a same-command git alias that carries a no-verify flag (umbrella; also covers #5203).

Current behavior:
Verified on main: $env:LEFTHOOK=0; git commit -m x, Set-Item env:HUSKY 0; git commit -m x, and git config alias.c 'commit -n'; git c -m x all pass the hook. The bash prefix form LEFTHOOK=0 git commit is already blocked.

Desired behavior:
PowerShell env assignment of any hook-manager disable variable ($env:X=0, $env:X = '0', Set-Item env:X 0, si env:X 0) before a git commit/push blocks exactly like the bash prefix form, reusing the same variable list. A git alias defined in the same command whose value carries --no-verify or -n for commit is blocked.

Acceptance criteria:

• One test case per shape above in the block-no-verify test suite, each expecting a block.
• The PowerShell forms read the same hook-manager variable list the bash form uses (no second list).
• Existing bash-form cases still pass.
• When this lands, close guardrails: block-no-verify allows $env:LEFTHOOK=0 before git commit #5203 as a duplicate of this issue.

Out of scope:

• Aliases defined in a previous command or in git config files (only same-command definitions).

[kyle-sexton]

This was generated by AI during triage.

#5203 is folded into this issue: its $env:LEFTHOOK=0 case is one of the shapes the brief above covers. Close #5203 as a duplicate when this lands.

[kyle-sexton]

Correction from the 2026-09-29 audit of the Cursor run: the parenthetical saying main already blocks [Environment]::SetEnvironmentVariable("LEFTHOOK","0") does not match what the audit observed.

Against guardrails on origin/main (git diff 29a36c991 origin/main -- plugins/guardrails empty at the time):

• LEFTHOOK=0 git commit -m x (Bash) exits 2 (blocked).
• $env:LEFTHOOK=0; git commit -m x (PowerShell) exits 0 (allowed).
• [Environment]::SetEnvironmentVariable('LEFTHOOK','0'); git commit -m x (PowerShell) exits 0 (allowed).

Suggest adding both PowerShell spellings to this issue's acceptance criteria, with a test per spelling.