guardrails: block-dangerous-git.sh blocks PowerShell commands that invoke no git command

[kyle-sexton]

Problem

block-dangerous-git.sh blocked a PowerShell command that invokes no git command at all.

Reproduction

A PowerShell script measuring directory sizes was blocked with:

BLOCKED: this PowerShell 'git' command cannot be parsed with confidence — blocked (fail-closed).
Trigger: a construct the guard cannot faithfully tokenize (backtick, '--%', subexpression, or {}/() grouping).

The command's only relationship to git was the literal string '.git' appearing inside an array membership test used to classify directory names:

Get-ChildItem -LiteralPath $p -Recurse -Force -Directory |
  Where-Object { $_.Name -in @('node_modules','obj','bin','.git') } |
  ForEach-Object { ... }

No git executable is invoked anywhere in it.

Analysis

Two independent failures compose here:

1. Detection: the guard appears to match the substring git against the command text rather than detecting git in command position. .git — a string that appears in most filesystem tooling on a developer machine — is enough to engage it.
2. Tokenization: having engaged, it then finds {} grouping it cannot parse and fails closed. But ForEach-Object { } and Where-Object { } are the ordinary way to write PowerShell; treating scriptblock braces as suspicious makes idiomatic PowerShell unrunnable.

The practical effect is that while the guard is active, most non-trivial PowerShell touching the filesystem is blocked, whether or not it has anything to do with git.

Proposed change

Detect an actual git invocation — command position, not substring — before engaging the tokenizer at all, so a command that never calls git is deferred instantly and never reaches the fail-closed path.

Acceptance criteria

• A PowerShell script containing the string .git but invoking no git command is not blocked.
• A genuine git reset --hard / git clean -fd / git checkout -- in any spelling the guard handles today is still blocked.
• The fail-closed behavior is retained for commands that do invoke git and cannot be tokenized.

[kyle-sexton]

Second reproduction, hit while filing this very issue — and it is a different trigger arm from the same root cause.

Creating the issue was blocked with:

Trigger: a process launcher or nested shell (Start-Process/saps/start, pwsh, powershell, cmd), which the guard must see through the way it sees through 'bash -c'.

The command launched no shell. It was a single gh issue create invocation. What tripped it was the issue title text itself, passed as a quoted string argument:

--title 'guardrails: block-dangerous-git.sh blocks PowerShell commands that invoke no git command'

The substring git engaged the guard, and the substring PowerShell inside the quoted title was then read as a nested-shell invocation.

This confirms the diagnosis in the original report and extends it: the guard is matching substrings against the raw command text without regard to shell quoting, so any string argument — a commit message, an issue title, a search pattern, a filename — can trigger both the engagement check and the launcher check. A guard whose bypass condition is "do not mention git or PowerShell in any string you pass to any program" is not workable on a developer machine.

Workaround used: gh api ... -F title=@file -F body=@file, sourcing both fields from files so the offending words never appear in the command line.

Worth adding to the acceptance criteria:

• A command that passes git, powershell, cmd, or start inside a quoted string argument to a non-shell program is not blocked.

[kyle-sexton]

A dedicated audit of this hook reproduced the reported behavior and isolated the root cause by single-variable experiment. Adding the mechanism, four adjacent findings, and two further false positives observed in ordinary work.

All blocks below were reproduced end-to-end by piping real PreToolUse payloads into the installed hook, producing block text byte-identical to the session quotes. Five blocks observed in one session, zero true positives.

Root cause of the no-git-command case

The trigger is a conjunction: a PowerShell grammar construct the tokenizer declines to parse, plus a git-looking substring anywhere in the command — including inside a quoted string literal that is never executed.

Proof by single-variable experiment. The verbatim blocked command mapped .git pointer files to owning repositories and contained no git invocation. Changing only the status label:

foreach (… '…-block-dangerous-git') { … }   →  EXIT=2  (blocked)
foreach (… 'beta-block-dangerous')    { … }  →  EXIT=0  (allowed)

and separately, the string 'NO-GIT' used as a status value supplied the entire git signal — renaming it to 'NO-REPO', changing nothing else, flipped the same command from EXIT=2 to EXIT=0.

Worth stating explicitly because an earlier note in our own evidence got this wrong: it is not "the grammar construct, not the substring". Either alone is allowed. Both together block.

Recommended primary fix is to require the git token in command-word position rather than anywhere in the string. Expressing it as a set of exceptions to the current match is the shape that historically regressed here (the #740/#903 fail-open class).

Two further false positives, both from ordinary work

git remote -v behind a subexpression. Read-only verb, blocked by the (Join-Path …) supplying -C:

git -C (Join-Path $mp 'melodic-software') remote -v

-C (Join-Path …) is the idiomatic way to run git against a directory that is not cwd — precisely what -C exists for. This one arose while inferring a repo for an unrelated task, not from a constructed probe.

The call operator with a constant literal target. Different trigger line, same outcome:

& 'C:\Program Files\Git\bin\bash.exe' '<script>' record '<dir>'

Two problems with that message's remediation as written:

1. "Write the program as a plain command word" is impossible for any path containing a space — i.e. everything under C:\Program Files\, which is the class of Windows path most likely to need it.
2. "Or run the command via the Bash tool" was simultaneously denied by disk-hygiene's still-armed belt (disk-hygiene: the Bash belt denies read-only supporting commands for the whole session #2591). In that session the two guards each named the other's lane as the escape hatch.

The workaround that finally worked is strictly weaker than what was blocked:

$env:PATH = 'C:\Program Files\Git\bin;' + $env:PATH
bash '<script>' record '<dir>'

The blocked form named an absolute constant path to a specific binary; the permitted form resolves bash through a mutable PATH the same command had just modified. Relatedly, & '…\Git\bin\bash.exe' blocks while an identical …\Msys2\bin\bash.exe is allowed — the discriminator is a directory name. The rule does not appear to be buying the security property it claims.

Four adjacent findings from the same audit

1. The PowerShell sink cannot be scoped. It calls exit 2 inline instead of routing through block(), so block_dangerous_git_allow can never apply to it. That is why the only escape the message offers is the global block_dangerous_git_enabled = false kill switch — an all-or-nothing lever offered in response to a read-only worktree list. The right-sized lever already exists and simply is not wired to this path.

2. A readonly-ok scope already exists and is not passed here. ps::classify_git_command accepts it and block-no-verify.sh:272 passes it; block-dangerous-git.sh:1355 does not.

3. That fix alone is insufficient, and shipping it alone would close this issue with the reported command still blocked: ps-command.sh:289 classes bare worktree as mutating. Both are needed. Note also that readonly-ok delegates to ps::git_command_is_readonly, a deny-list whose default for an unenumerated verb is allow — with no true positive exercised anywhere in this evidence, that widens allow across every verb nobody listed. An explicit read-only allowlist (log, status, worktree list, for-each-ref, rev-parse, show, diff, remote -v) is the safer destination.

4. Nothing told the maintainers. PS_SINK_TRIGGER telemetry exists precisely to detect over-blocking and is opt-in and unset by default, so five false positives in one session produced zero maintainer signal.

Hard constraint on any fix

No true positive is exercised anywhere in this evidence — the guard's accuracy on real reset --hard, clean -fd, checkout, or force-push shapes is untested here. Every change above must be regression-tested against block-dangerous-git.test.sh. A fix that reduces false positives by weakening real detection would be strictly worse than the current state.

Also flagged for sequencing: any proposal to return permissionDecision: "ask" instead of exit 2 for the unparsable sink should be held until the open question on #2595 is settled — a hook-issued ask is exactly the control whose reliability under non-default permission modes is currently in question.

Environment: Windows 11 26200, PowerShell 7. block-noncanonical-commit.sh:956 and block-convention-violation.sh:457 inherit the same shared-library behavior. The lease and object-id-width machinery (~a third of the file) and the entire Bash lane were not audited.

[kyle-sexton]

Claimed by cloud orchestrator lane guardrails (Wave 1).

[kyle-sexton]

Residual filed as issue 2848. PR 2622's command-position fix works — this issue's own reproduction is allowed today on all three blocking hooks. What it does not reach is the conjunction of a grouping construct and a bare-computed call target, which is still rc=2 on all three and pinned by no test. The new issue is scoped to that shape only and does not re-litigate this one.