fix(guardrails): allow read-only git inside PowerShell grouping

[kyle-sexton]

Refs: #4235

Summary

A PowerShell command with {}/() grouping was refused by block-dangerous-git even when every git call in it was read-only, so foreach ($d in ...) { git -C $d status; git -C $d log } failed. Guardrails goes to 0.44.1.

The owner decided on #4235 (2026-09-30) how the environment-write guard in that relief must work, Option A: "Parse, do not substring-match: block any Env: write (Set-Item/New-Item/${env:...}/[Environment]::SetEnvironmentVariable) whose target name is not a literal string, fail closed. Add regression cases for a concatenated and a computed Env: path." This PR implements that decision. The Claude security lane's CRITICAL thread on the earlier substring guard (PRRT_kwDOTCGFQM6nlUph) is still open, and a newer one on the location-change arm (PRRT_kwDOTCGFQM6nqcu1) is addressed by 2b63cb907; both stay for the lane to re-judge. The PR is a draft until then.

Issue #4235 has two acceptance criteria beyond the relief:

• The block-no-verify narrow-token criterion is met on main by fix(guardrails): PowerShell fail-closed sink allow token clears mutating block (#4252) #4833 (block-no-verify.sh honors ps-unparsable-special-construct from block_dangerous_git_allow).
• The block-hook-bypass ps-computed-positional criterion is not implemented. The owner excluded it in the PR fix(guardrails): PowerShell read-only git grouping + ps-computed-positional (#4235) #4817 close comment, so the PR uses Refs, not Closes. The owner decides whether to strike that criterion and close the issue.

Fix

• New interrogation-ok sink scope in ps::classify_git_command. It relieves only the special-construct trigger, and only when every git invocation is on the ps::git_command_is_interrogation_only allowlist (status, log, show, diff, rev-parse, ls-files, remote -v, stash list and similar), optionally behind -C <path>. -c, --exec-path, computed or obscured subcommands, aliases, fetch, grep and mutating verbs still block. Dynamic-invocation, launcher and here-string triggers are unchanged.
• ps::has_unprovable_env_write replaces the seven substring checks for the environment-write guard. It reads syntax and refuses whatever it cannot prove has a plain literal target: a provider cmdlet (Set-/New-/Add-/Copy-/Move-/Rename- Item, Content, ItemProperty, their aliases, mkdir) whose operands are not plain words or that has no operand; an Env:/Function:/Alias: drive path; a $env:NAME assignment, alone, in a target list or as a foreach variable; a static :: call; any method call; ForEach-Object -MemberName; a computed call target; a word spliced from quoted parts (Set'-'Item, E'nv':X); a function, filter or alias definition; Add-Type, New-PSDrive, Invoke-Command; a $( ) inside an expandable string; and a write beside a Set-Location/cd whose target is computed or piped in.
• ps::git_command_is_readonly judges remote and stash by arguments instead of listing them as mutating stems.
• The sink denial offers the commit form only for a commit and names the PowerShell rewrite first, including the fallback line for an unrecognized trigger.
• README note and CHANGELOG entry updated; version 0.44.1 (main is at 0.44.0).

Trade-off the owner may want to weigh: the scan refuses ordinary idioms that contain a method call, a static call or "$($x.Name)" inside a group with git, because it cannot prove them harmless. An operator unrolls the loop into flat statements, computes the value into a variable first, or sets ps-unparsable-special-construct. It does not read code in a file, or a script block held in a variable and run by a cmdlet that accepts one. The broader alternative (relieve only commands whose every command word is on an allowlist) stays available and is the owner's call.

Verification

• The four commands from the verifier now exit 2 (each returned 0 on the earlier head): $n = "GI"+"T_PAGER"; New-Item -Path ("E"+"nv:") -Name $n ...; & { git log }, $p = "E"+"nv:\GI"+"T_PAGER"; Set-Item $p ...; & { git log }, Set-Content -Path ("E"+"nv:" + $e) ...; & { git log }, and the Type.InvokeMember form.
• I ran 64 environment-write variants in real PowerShell 7.6 and confirmed each one sets the variable; the guard refuses all 64 beside & { git log }. They include splat, pipeline and variable-held paths, ForEach-Object -MemberName, reflection, Set-Alias, script blocks, and Set-Location -Path $computed followed by a relative write.
• block-dangerous-git.test.sh: 815 cases pass, including new rows for a split Env: token, a path held in a variable, InvokeMember, and the variants above, plus predicate pins that test ps::has_unprovable_env_write on its own. All 25 guardrails suites pass; shellcheck is clean on the changed .sh files.
• scripts/check-changelog-parity.sh --check, --check-order, --check-preserved origin/main, --check-bump origin/main and scripts/validate-plugins.sh pass at this head.
• bash scripts/affected-tests.sh --run --jobs 8 origin/main: 430 shell suites run, and the only failures are three suites that need tools this host lacks (check-html-assets.test.sh and check-script-contract.test.sh need htmlhint; hook-census.test.sh needs strace).
• scripts/check-guardrails-ps-differential.sh origin/main over 837 commands: the only cells that move are 19 unique read-only git commands (for example & { git status --porcelain }, (git diff) > out.txt) that main refused and the branch allows. The block-no-verify, convention, noncanonical, hook-bypass and delete rows show 0 moved cells, and no command is refused by the branch that main allows. The script reports the loosened cells by design.

Related

• guardrails: read-only git inside {} blocked by two guards, with irrelevant commit guidance, Bash-lane advice, and no narrow lever #4235, guardrails: all guards run after a block, and the README does not document the PowerShell over-blocks #4236, fix(guardrails): PowerShell fail-closed sink allow token clears mutating block (#4252) #4833, fix(guardrails): PowerShell read-only git grouping + ps-computed-positional (#4235) #4817
• fix(guardrails): judge more shell shapes, declare node, correct docs #5340 also edits ps-command.sh; main was merged into this branch twice since it opened.

🤖 Generated with Claude Code

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-30T19:29:23.426248Z	557b7e6	Draft marked ready

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2d72cd409a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Claude finished @kyle-sexton's task in 9m 50s —— View job

---

Security review complete

• Gather context (PR diff, changed files)
• Read ps-command.sh classification/allowlist logic in detail
• Read block-dangerous-git.sh, block-no-verify.sh, and their tests
• Hunt for bypass paths in the new interrogation-ok sink scope
• Check instruction-surface deletions (guardrail loosening) against protected classes
• Post findings

No security issues found.

This PR touches plugins/guardrails security-guard logic directly, so I gave it a thorough adversarial pass rather than a cursory one. Summary of what I checked and why it holds up:

The core change (ps::git_command_is_interrogation_only in ps-command.sh) narrows block-dangerous-git's fail-closed PowerShell-grouping sink so that a {}/() group containing only read-only git calls (status, log, show, diff, argument-aware remote/stash, etc.) is allowed through instead of blocked outright.

This is a loosening of a hook's block condition guarding irreversible git actions (reset --hard, push --force, clean -f, checkout -f/., restore .), one of the protected classes in docs/conventions/instruction-exception-register/README.md. I applied that lens and traced whether anything still enforces the removed friction. It does: the new allowlist function requires every git token in the entire command text (not just inside the grouping construct) to resolve to a literal, argv-position-verified interrogator, with the dangerous verbs (reset, push, clean, checkout, restore, fetch, grep, -c, --exec-path, computed/obscured subcommands, aliases) simply absent from the allowlist. I tried to construct bypasses — mixed safe+mutating calls in one group, ('re'+'set')-style obscured subcommands, $sub-computed subcommands, -c core.pager=, --exec-path=, alias-shaped subcommands (git co), quoted-string hiding, and case-boundary tricks around -C vs -c — and in each case the function's argv-aware tokenizer (built over a quote-opaqued string, so a quoted git reset can't hide a real one, and a real one can't hide in a quote) correctly refuses. The PR's own test additions in block-dangerous-git.test.sh cover this same adversarial set (mixed mutating-in-group, obscured/computed subcommand, -c/--exec-path, alias, launcher, iex beside a safe group) and all assert blocked. So this is a rule a mechanism still enforces, not an unmitigated deletion.

Other angles checked:

• Whether --output=<file>-style git flags (a real write-to-arbitrary-path vector on log/diff/show) become newly reachable through the new allowlist. They don't — block-dangerous-git's blocklist never covered that flag family for any invocation shape, grouped or not, before or after this PR (it's an explicitly documented, pre-existing, out-of-scope tradeoff in ps::git_command_is_readonly's header comment, deferred to "write-side guards"). Not something this PR changes.
• The remote/stash argument-aware carve-out (used by block-no-verify's readonly-ok scope) against the same class of tricks (-v before a mutating verb, safe-then-mutating in one command) — also correctly refuses, and is explicitly tested.
• The denial-message wording changes (which form to suggest) are informational only, printed to stderr, no injection surface.
• No secrets, credentials, or auth logic touched.

[claude]

Code review in progress

• Gather context (PR body, CLAUDE.md/AGENTS.md conventions, diff)
• Review changed hook scripts (block-dangerous-git.sh, block-no-verify.sh, block-convention-violation.sh, block-noncanonical-commit.sh)
• Review lib/powershell/ps-command.sh classifier changes
• Review test coverage (block-dangerous-git.test.sh, block-no-verify.test.sh)
• Review README/CHANGELOG/plugin.json version bump
• Post inline findings and summary

View job run

[github-actions]

PR body contract — issue linkage

This PR body conforms to the issue-linkage contract. Nothing to do.

[claude]

Claude finished @kyle-sexton's task in 3m 45s —— View job

---

Security review complete

• Gather context (PR body, full diff via gh pr diff, prior review comments)
• Re-review the latest commit (1268017) that hardened the GIT_* environment-variable check against the Codex-flagged ${env:GIT_...} gap
• Trace the interrogation-ok sink scope end-to-end for further bypasses, checked against the instruction-exception-register's irreversible-action/RCE lens
• Post findings

1 CRITICAL finding, posted inline on ps-command.sh#L1669:

The 1268017 commit added [[ "$lc" =~ env:[/\\]?git_ || "$lc" == *setenvironmentvariable* ]] to ps::git_command_is_interrogation_only, closing the literal ${env:GIT_EXTERNAL_DIFF} / Env:\GIT_PAGER / [Environment]::SetEnvironmentVariable(...) spellings Codex flagged. But it's a raw substring match over the assembled command text, so it only catches a contiguous env:git_ spelling. Any non-literal construction of the same Env: provider path evades it while still setting the variable at runtime, e.g.:

Set-Item -Path ('Env:' + 'GIT_PAGER') -Value 'C:\evil.exe'; & { git log }

lc here is ...('env:' + 'git_pager')...; & { git log } — no contiguous env:git_, no setenvironmentvariable substring, and none of has_dynamic_invocation/has_launcher/the call-target checks fire either (it's a plain cmdlet call with concatenated argument text, not a dynamic call target). The trailing & { git log } grouping is exactly what this PR sets out to allow, git log is on the interrogator allowlist, so the whole line is classified interrogation-ok and reaches git — where GIT_PAGER executes the attacker's binary. Same gap applies to -join, -f, or a variable holding the var name. This is the same class of trick the commit message says it closes ("refuse every GIT_* environment spelling"), and none of the new tests in block-dangerous-git.test.sh use a non-literal spelling, so the gap has no failing test today.

Everything else checked out:

• The core interrogation-ok allowlist logic (bare-command-word requirement, quote-opaqued tokenizer, argv-position -C/--exec-path/-c handling, obscured/computed/alias subcommand refusal) matches what the prior Claude and Codex reviews already validated against this same adversarial set, and I didn't find a new gap there.
• remote/stash argument-aware carve-outs still correctly refuse a mutating verb anywhere in the command.
• No GitHub Actions / workflow files are touched by this PR (defer to zizmor for that surface regardless).
• No secrets or credential handling touched.

[claude]

Claude finished @kyle-sexton's task in 4m 58s —— View job

---

Code review (correctness & maintainability)

• Gather context (PR diff, changed files, CLAUDE.md/AGENTS.md conventions)
• Review ps-command.sh classifier changes (ps::git_command_is_interrogation_only, ps::git_command_is_readonly remote/stash carve-out, interrogation-ok sink scope)
• Review changed hook scripts (block-dangerous-git.sh, block-no-verify.sh, block-convention-violation.sh, block-noncanonical-commit.sh)
• Review test coverage (block-dangerous-git.test.sh, block-no-verify.test.sh)
• Review README/CHANGELOG/plugin.json version bump
• Post findings

No correctness or maintainability findings.

This lane is scoped to correctness/maintainability; a security lane already ran a
thorough adversarial pass on this branch (see the separate "Security review
complete" comment above), so bypass-style concerns (e.g. the GIT_*
environment-variable spelling the Codex review flagged) are intentionally left
to that lane rather than duplicated here — and this PR's latest commit
(1268017) already addresses it by refusing env:[/\\]?git_ and
SetEnvironmentVariable in
ps-command.sh#L1669.

What I checked for correctness:

• Traced ps::git_command_is_interrogation_only's argv-tokenizer (option-skipping
  for -C <path>/--no-pager/-P/--no-optional-locks/--literal-pathspecs,
  the remote/stash argument-aware branches, and the quote-opaqued token count
  vs. probe count) against the new test matrix in block-dangerous-git.test.sh
  and confirmed each traced case (obscured/computed subcommand, -c, --exec-path,
  alias, mixed safe+mutating in one group, launcher/iex/nested-pwsh) resolves the
  way the test asserts.
• Confirmed all four ps::print_unparsable_block_message "$COMMAND" call sites
  (block-no-verify.sh L327/L339, block-convention-violation.sh L626,
  block-noncanonical-commit.sh L939) pass the command text that is current at
  the point of the call (post-blanking in block-no-verify.sh's loop, raw
  elsewhere), so the new commit-form-only-for-a-commit gate reads the right text
  in each case.
• Cross-checked the README/CHANGELOG wording against the implementation
  (interrogator list, -C/remote/stash carve-outs, the reordered
  special-construct trigger message) — all consistent, and plugin.json's
  0.42.1 bump matches the new CHANGELOG heading.
• Noted (not a blocking finding, just an observation): ps::git_command_is_interrogation_only's
  allowlist is narrower than ps::git_command_is_readonly's blocklist for a few
  plumbing forms (e.g. git merge-tree, allowed by block-no-verify's
  readonly-ok scope but not by block-dangerous-git's interrogation-ok
  allowlist) — this looks like an intentional, documented tradeoff (the new
  function is a from-scratch allowlist, not required to mirror the older
  blocklist's coverage) rather than a bug.

Author-claimed verification (changelog parity checks, shellcheck, the 422-suite
affected-tests.sh run, the PS differential script) is unverified by me — I did
not independently re-run those.

[claude]

Claude finished @kyle-sexton's task in 3m 7s —— View job

---

Security review complete

• Load /review:security-review skill and follow its criteria
• Check skip gate (open PR, security-relevant surface, prior review currency at this HEAD)
• Gather diff and read changed files
• Re-verify the prior CRITICAL finding (GIT_* env-var substring bypass) against current HEAD 1a3fcb2
• Check instruction-surface deletions against protected classes in the instruction-exception-register
• Hunt for additional injection/bypass paths in the new interrogation-ok sink scope
• Post findings

1 CRITICAL finding (unresolved carry-forward) — posted inline on ps-command.sh#L1669:

ps::git_command_is_interrogation_only's GIT_* environment-variable guard (env:[/\\]?git_ / setenvironmentvariable) is a literal-substring match over the assembled command text, so only a contiguous spelling of the Env: provider path is refused. A concatenated/computed construction still sets the variable at runtime while evading the check:

Set-Item -Path ('Env:' + 'GIT_PAGER') -Value 'C:\evil.exe'; & { git log }

No contiguous env:git_ substring appears, setenvironmentvariable doesn't appear, and none of the dynamic-invocation/launcher/call-target checks fire (this is a plain cmdlet call with concatenated argument text). The trailing & { git log } grouping is the {} shape this PR exists to allow, git log is on the interrogator allowlist, so ps::classify_git_command classifies the whole line interrogation-ok and block-dangerous-git lets it through — at which point GIT_PAGER executes the attacker's binary as git's pager. Same gap for -join, -f, or a variable holding the var name.

This is the identical gap a prior review on this PR already flagged as CRITICAL at commit 1268017 (the commit whose own message says "refuse every GIT_* environment spelling"). I confirmed plugins/guardrails/lib/powershell/ps-command.sh is byte-for-byte unchanged between 1268017 and the current head 1a3fcb2 (git diff 1268017 1a3fcb2 -- plugins/guardrails/lib/powershell/ps-command.sh is empty — the only commits added since then are an unrelated origin/main merge). None of the three GIT_*-env tests added in block-dangerous-git.test.sh (lines 984-991) use a non-literal spelling, so the gap has no failing test today.

Instruction-surface lens: this PR loosens block-dangerous-git's fail-closed PowerShell-grouping sink, which guards the irreversible-action protected class (reset --hard, push --force, clean -f, etc.). The new interrogation-ok allowlist still explicitly refuses every mutating verb and every obscured/computed/aliased subcommand form I could construct, so the loosening is mechanism-enforced everywhere except the GIT_* env-var path above, which is exactly a bypass of that protection (redirecting git's own pager/diff/credential helpers to run an arbitrary binary) reached through the very grouping shape this PR allows.

Other angles checked, no new issues:

• remote/stash argument-aware carve-outs still correctly refuse a mutating verb anywhere in the command.
• --output=<file>-style git flags remain out of scope for both the old blocklist and the new allowlist (pre-existing, documented tradeoff, not introduced by this PR).
• No GitHub Actions/workflow files touched (zizmor's lane regardless).
• No secrets or credential handling touched directly.
• README/CHANGELOG/plugin.json version bump are consistent with the implementation; no other guardrails files changed since the last review pass (block-windows-drive-tmp.sh changes visible in the diff stat came in from the origin/main merge, not this PR's own commits).

[claude]

Claude finished @kyle-sexton's task in 2m 5s —— View job

---

Code review (correctness & maintainability) — /review:code-review

• Gather context (PR diff via gh pr diff 5548, changed-file list, prior review comments)
• Check for a still-applicable prior review from this lane
• Report

Skipping deep review: no new substantive changes since the last code-review-lane pass on this branch.

This trigger fired on a synchronize event, but the only difference between the head reviewed by the prior "Code review (correctness & maintainability)" comment (commit 1268017) and the current head (1a3fcb2) is a merge of origin/main into the branch. Diffing the PR's own 10 changed files between those two commits (git diff 1268017 1a3fcb2 -- <the 10 files>) shows only:

• plugin.json / CHANGELOG.md heading/ordering churn from interleaving with main's own changelog entries
• One README.md table row (block-windows-drive-tmp) that changed only because main's unrelated commit dab0b0a touches the same file — not new content from this PR's authors

No lines in ps-command.sh, block-dangerous-git.sh, block-no-verify.sh, block-noncanonical-commit.sh, block-convention-violation.sh, or either .test.sh changed. That prior review's correctness/maintainability findings (none) still apply as-is; author-claimed verification (changelog-parity script, shellcheck, the 422-suite run) remains unverified by me, consistent with that review.

Note on the open security thread: the security lane's CRITICAL finding on ps-command.sh#L1669 (the GIT_* env-var guard is a literal-substring check, bypassable via Set-Item -Path ('Env:' + 'GIT_PAGER') ...-style concatenation) is still present in the code at this head — I confirmed the line is byte-for-byte unchanged since that review. That's a security finding and stays with the security lane per this lane's scoping rule; flagging its presence here only so it isn't lost in the noise of this synchronize event.

[claude]

Claude finished @kyle-sexton's task in 3m 24s —— View job

---

Code review (correctness & maintainability) — /review:code-review

• Gather context (PR diff via gh pr diff 5548, changed-file list, prior review comments)
• Determine what changed since the last code-review-lane pass (commit 1a3fcb2) — real: commit 5b0236f "refuse environment writes in the read-only git group check" plus a merge of origin/main
• Review the new environment-write guard (ps-command.sh) for logic/tokenizer correctness
• Review remaining changed files (hooks, tests, README/CHANGELOG/plugin.json) for consistency
• Post findings

1 finding, posted inline on README.md:185:

The README bullet documenting interrogation-ok (what still blocks a grouped PowerShell command) omits the environment-write refusal (GIT_* name, Env: provider path, $env:NAME/${env:NAME} assignment, SetEnvironmentVariable) that ps::git_command_is_interrogation_only enforces and that this same release's CHANGELOG entry explicitly calls out. The README's account of the guard's behavior is now incomplete relative to the code and the CHANGELOG for this change.

What I checked and found no issue with:

• The interrogation-ok sink-scope wiring: block-dangerous-git.sh passes it on both ps::classify_git_command call sites (initial and in-loop re-classify); block-no-verify.sh still uses readonly-ok (unchanged), consistent with the PR description's claim that block-no-verify's narrow-token criterion is a separate, already-merged fix (fix(guardrails): PowerShell fail-closed sink allow token clears mutating block (#4252) #4833).
• ps::classify_git_command's gating of interrogation-ok to the special-construct trigger only (ps-command.sh L2099-2101).
• The tokenizer in ps::git_command_is_interrogation_only (argv-position -C/--no-pager/-P/etc. skipping, the remote/stash argument-aware branches, the quote-opaqued token count vs. probe count) against the new test matrix in block-dangerous-git.test.sh — each traced case resolves the way the test asserts.
• The ps::print_unparsable_block_message commit-form gating change: all four call sites (block-convention-violation.sh, block-no-verify.sh ×2, block-noncanonical-commit.sh) were updated to pass "$COMMAND"; block-dangerous-git.sh calls a separate, untouched ps::print_unparsable_git_block_message so it's correctly out of scope for this change.
• plugin.json (0.42.4) and the CHANGELOG heading are consistent; the CHANGELOG's own 0.42.4 bullet is accurate and complete (it's the README that lags, not the CHANGELOG).

Not independently verified: I could not execute the shell test suites in this sandbox (command execution requires approval this session doesn't grant), so the author-claimed verification (affected-tests.sh, shellcheck, the changelog-parity checks, the PS differential script) is unverified by me, consistent with the prior code-review-lane pass on this branch.

Note on the open security thread: the security lane's previously-flagged CRITICAL finding (the GIT_* env-var guard being a literal-substring check, bypassable via Set-Item -Path ('Env:' + 'GIT_PAGER') ...) appears to be what commit 5b0236f addresses — I did not re-verify the fix's completeness, since bypass-style concerns are that lane's scope, not this one's.

[claude]

Claude finished @kyle-sexton's task in 4m 5s —— View job

---

Security review complete

• Gather context (PR body, prior review comments, diff)
• Invoke /review:security-review and follow it exactly for this PR (repo melodic-software/claude-code-plugins, PR fix(guardrails): allow read-only git inside PowerShell grouping #5548, HEAD e73a45a)
• Post findings

1 CRITICAL finding, posted inline on ps-command.sh#L1790-L1798:

Commit 5b0236f (already merged into this HEAD) widened the GIT_* environment-variable guard in ps::git_command_is_interrogation_only — it now correctly refuses the previously-flagged Set-Item -Path ('Env:' + 'GIT_PAGER') ... bypass (verified against the new block-dangerous-git.test.sh:994 case). But the widened guard is still five textual substring/regex checks over the assembled command, not an argv-aware proof. A .NET-reflection call that never spells GIT_, SetEnvironmentVariable, or Env: contiguously still evades all five and still classifies interrogation-ok:

$m = [Environment].GetMethod(('Set'+'EnvironmentVariable'), [Type[]]@([string],[string]))
$m.Invoke($null, [object[]]@(('GI'+'T_PAGER'), 'C:\evil.exe'))
& { git log }

None of *git_*, the env: check, *environment::*, *setenvironmentvariable*, or the $env:-prefixed assignment regex fire (the name and method are split across string-concatenation, and this never touches the Env: PSDrive at all). The trailing & { git log } is the exact grouping shape this PR sets out to allow, so block-dangerous-git lets the whole statement through, and GIT_PAGER then runs the attacker's binary as git's pager — the same RCE class two prior review rounds already flagged CRITICAL on this function, reached through reflection instead of the Env: drive. Full technical walkthrough (including why the split point 'GI'+'T_PAGER' specifically, not 'GIT'+'_PAGER', is needed to also evade the git-token quote/opaque-count check) is in the inline comment.

A substring/regex approach can't close this class by construction — each literal spelling added closes only that spelling. The fix needs the same argv-aware treatment the git-token walk in this same function already required for the word git itself.

Other angles checked, no new issues:

• remote/stash argument-aware carve-outs, the obscured/computed/alias subcommand refusals, and -c/--exec-path handling in the allowlist walk all still hold against the adversarial set prior reviews already validated.
• block-dangerous-git.sh / block-no-verify.sh pass interrogation-ok / readonly-ok through unchanged from what prior reviews already covered.
• No GitHub Actions/workflow files touched by this PR.
• No other secrets/credential handling touched.

[claude]

Claude finished @kyle-sexton's task in 5m 8s —— View job

---

Code review (correctness & maintainability) — /review:code-review

• Gather context (PR diff, prior review comments on this branch)
• Determine what changed since the last code-review-lane pass (commit 1ea08e5) — real: commit daee34b "judge environment writes in the read-only git group by syntax" (plus a merge of origin/main)
• Review the rewritten environment-write guard (ps::has_unprovable_env_write, ps::_is_plain_word) for logic/maintainability
• Confirm the other files in this PR's change set are unchanged since the last pass
• Check README/CHANGELOG/plugin.json consistency
• Post findings

No correctness or maintainability findings.

Since the last code-review-lane pass on this branch (reviewing 1ea08e5), the only
real content commit is daee34b, which replaces the seven-substring env-write
guard (the subject of the still-open security thread on this PR) with a
syntax-based scan, ps::has_unprovable_env_write + ps::_is_plain_word in
ps-command.sh.
I confirmed the other files in this PR's 10-file change set
(block-no-verify.sh, block-no-verify.test.sh, block-convention-violation.sh,
block-noncanonical-commit.sh) are byte-for-byte unchanged since 1ea08e5; only
plugin.json's version (0.43.4) and CHANGELOG.md's heading moved, and that
move is the expected renumbering from interleaving with origin/main's own
0.43.3 entry in the merge — confirmed the merge commit resolved this correctly
(new 0.43.3 section inserted from main, this PR's entries kept under a new
0.43.4 heading, plugin.json bumped to match).

What I checked in daee34b:

• Traced the new tokenizer (statement/pipe/brace splitting to ;, paren/comma/=
  as standalone tokens, the ${env:NAME} → $env:NAME fold, the quote-opaquing
  pass) against the ~27 new blocked-case rows and ~4 new allowed-case rows in
  block-dangerous-git.test.sh, plus the pre-existing rows this rewrite had to
  keep passing (braced ${env:GIT_EXTERNAL_DIFF}, Set-Item Env:\GIT_PAGER,
  [Environment]::SetEnvironmentVariable, the concatenated-path and
  reflection/InvokeMember cases from earlier rounds) — each traced case
  resolves the way its test asserts, including the target-list/foreach-variable
  scan (lines 1826-1844), the provider-cmdlet operand walk with its -Value
  skip-and-parenthesized-skip logic (1855-1900), and the write_head && dyn_cd
  combination for a computed Set-Location beside a relative write (1853, 1904).
• Confirmed the removed ps::call_target_is_bare_subexpression "$recovered" && return 1
  line (previously inline in ps::git_command_is_interrogation_only) isn't a
  coverage gap: ps::has_unprovable_env_write now reaches the same shape through
  ps::call_target_is_bare_computed (line 1801), whose pattern
  ([.&][[:space:]]*[\$\(]) is a strict superset of the removed predicate's
  ([.&][[:space:]]*\$?\() — it additionally catches the bare-variable form
  (& $tool), which is a tightening, not a loosening.
• No leftover references to the removed inline variables (env_read, the old
  env_assign local) elsewhere in the file.
• README (README.md:184-207) and the CHANGELOG.md 0.43.4 entry both
  describe the syntax-based behavior accurately and consistently with each
  other and with the code (provider-cmdlet operand rule, Env:/Function:/Alias:
  drives, target-list/foreach forms, static/method calls, ForEach-Object -MemberName, computed call targets, function/filter/alias definitions, the
  "code in a file" / "script block held in a variable" residual).
• The sink-trigger fallback message change (ps::print_sink_trigger_line,
  leading with the PowerShell rewrite) matches its own new test assertion and
  the CHANGELOG bullet.

Not independently verified: I don't have permission to execute shell
commands in this sandbox this run (every Bash invocation, including a bare
pwsh -v probe, required approval that wasn't available), so I could not run
block-dangerous-git.test.sh itself or any of the author-claimed verification
(affected-tests.sh, shellcheck, changelog-parity checks, the PS differential
script). My read of the new test rows against the implementation is static
tracing, not execution.

Note on the open security thread: whether this syntax-based rewrite fully
closes the bypass class the security lane has been flagging (each prior fix
closing one literal spelling, defeated by the next split) is that lane's call,
not this one's — I did not duplicate that adversarial analysis here, beyond
confirming the rewrite is a different kind of check (a positional/operand
parse rather than a spelling list), which is the structural change two rounds
of security findings on this PR pointed toward.

[claude]

Claude finished @kyle-sexton's task in 5m 36s —— View job

---

Security review complete

• Load /review:security-review skill and follow it exactly for this PR (repo melodic-software/claude-code-plugins, PR fix(guardrails): allow read-only git inside PowerShell grouping #5548, HEAD e51802c)
• Check skip gate: PR open, security-relevant surface, but a prior review's finding was still open — not skipped
• Determine what changed since the last reviewed HEAD (1ea08e5): one real commit, daee34b "judge environment writes in the read-only git group by syntax", which fully replaces the substring/regex env-write guard with a syntax-aware parser (ps::has_unprovable_env_write); the rest is version-bump churn from an origin/main merge
• Re-verify the prior open CRITICAL finding (env-write guard bypassed by split/reflected names) against the new syntax-based guard
• Post findings

1 CRITICAL finding (new bypass in the rewritten guard), posted inline on ps-command.sh#L1853:

daee34b abandons the text-substring approach every prior review round on this PR defeated with a new literal spelling, and instead parses the syntax of an environment write (ps::has_unprovable_env_write). This closes the whole class of "name built from string pieces" bypass — I could not reconstruct any of the earlier Set-Item -Path ('Env:'+'GIT_PAGER'), [Environment].GetMethod(...).Invoke(...), or Type.InvokeMember proofs-of-concept against it, and the new test rows in block-dangerous-git.test.sh (lines 1000-1068, plus the unit rows at 1337/1357) confirm the same cases the prior reviews raised are now covered, including the "computed drive then relative write" shape at line 1037.

But the Set-Location/cd/chdir/Push-Location/pushd half of that same guard (line 1853) only inspects the single token immediately after the command word to decide whether the destination is computed (dyn_cd). ps::_is_plain_word's character class includes - and letters, so a bare flag like -Path or -LiteralPath satisfies it trivially — meaning Set-Location -Path $computed never sets dyn_cd, because the check looks at the flag, not the value one token later. Combined with a relative-path write (Set-Item GIT_PAGER 'C:\evil.exe', which passes its own operand check since git_pager reads as a plain literal name), the full command:

$d = 'Env' + ':'
Set-Location -Path $d
Set-Item GIT_PAGER 'C:\evil.exe'
& { git log }

evades every check in ps::has_unprovable_env_write (traced line-by-line in the inline comment) and is classified interrogation-ok, so block-dangerous-git lets it through. At execution, git log runs with GIT_PAGER pointed at the attacker's binary — the identical RCE class flagged CRITICAL in every prior round on this PR, now reached because Set-Location's detection is a single-token check where Set-Item/Set-Content/etc. (a few lines below, in the same function) already get a full argument walk that correctly handles named parameters and parenthesized values (verified against the passing -Path (...) test cases at lines 1000/1022). Only the bare-argument Set-Location form is tested (line 1037); the named-parameter form is not.

I was not able to execute the shell test suite in this sandbox (command execution requires approval this session doesn't grant, consistent with every prior review pass on this branch), so this is a static trace of the tokenizer logic, not a confirmed dynamic run — the full trace supporting each step is in the inline comment.

Other angles checked, no new issues:

• The interrogation-ok sink-scope wiring, the git-token allowlist walk, and the remote/stash argument-aware carve-outs are unchanged from prior rounds and still hold.
• ps::call_target_is_bare_computed now subsumes the old ps::call_target_is_bare_subexpression call site (removed from ps::git_command_is_interrogation_only); tracing both & $var and & (...) forms through the new guard, both still correctly refuse.
• No GitHub Actions/workflow files touched by this PR.
• No other secrets/credential handling touched; the other 9 files in this PR's change set are unchanged since the last review pass beyond version-bump/changelog churn from the origin/main merge (verified via git diff daee34b e51802c restricted to this PR's file list).

[claude]

Claude finished @kyle-sexton's task in 5m 4s —— View job

---

Security review complete

• Gather context (PR body, prior review comments, diff)
• Invoke /review:security-review and follow it exactly for this PR (repo melodic-software/claude-code-plugins, PR fix(guardrails): allow read-only git inside PowerShell grouping #5548, HEAD af771d6/557b7e6)
• Re-verify the prior open CRITICAL finding (Set-Location -Path $computed bypass) against current HEAD
• Hunt for further bypasses in the rewritten location-change check
• Post findings

No security issues found — the prior open CRITICAL finding is fixed.

What changed since the last reviewed HEAD (e51802c): two real commits, 2b63cb9 ("judge a location change's operands as a write's are") and af771d6 (CHANGELOG wording), plus a merge of origin/main. I confirmed only ps-command.sh, block-dangerous-git.test.sh and CHANGELOG.md differ from e51802c; no other file in this PR's 10-file change set moved.

The fix. The previously-flagged bypass was that ps::has_unprovable_env_write's Set-Location/cd/Push-Location case only inspected the single token immediately after the command word, so a named parameter (Set-Location -Path $computed) looked at the flag (-path, itself a "plain word") instead of the actual computed value one token later, letting dyn_cd go unset. 2b63cb9 extracts the full argument walk that Set-Item/Set-Content/etc. already had into a shared helper, ps::_operands_plain_to (ps-command.sh#L1759), and now runs it for the location-change case too (ps-command.sh#L1907):

set-location | sl | cd | chdir | push-location | pushd) ps::_operands_plain_to nlit "${t[@]:k+1}" && ((nlit)) || dyn_cd=1 ;;

I traced this against the exact PoC from the prior round ($d = 'Env' + ':'; Set-Location -Path $d; Set-Item GIT_PAGER 'C:\evil.exe'; & { git log }): the walk now skips only the flag token and validates the following value token regardless of whether it arrived positionally or after a named parameter, so $d correctly fails ps::_is_plain_word and sets dyn_cd=1, which combines with write_head=1 from the Set-Item a statement later to refuse the command. This exact case, plus a pipeline-arrival form ($d | Set-Location), a colon-form named parameter (Push-Location -LiteralPath:$d), and mkdir (newly added to the provider-cmdlet list), all gained run_pwsh-executed regression tests in block-dangerous-git.test.sh asserting blocked — these run through real pwsh, not just predicate pins, so they exercise actual PowerShell parsing semantics.

Additional adversarial checks I ran on the rewritten helper, no new gap found:

• Splat (Set-Location @h): @h fails ps::_is_plain_word (@ isn't in its character class) → correctly flagged computed.
• Parenthesized value after a named flag (Set-Location -Path (...)) : the ( token itself fails the plain-word check (only -Value's content gets the parenthesis-skip treatment) → correctly flagged.
• A variable hidden inside a double-quoted interpolated string (Set-Location "$part1$part2") — I initially suspected this might opaque down to the same _q_ placeholder as a true literal and slip past, but the quoting walker (ps-command.sh#L626-631) already emits a distinct $q placeholder (literal $+q) for any double-quoted span containing $, specifically to keep it distinguishable from a true literal. ps::_is_plain_word("$q") correctly fails since $ isn't in its allowed character class, so this is not a bypass — the existing design already accounts for it.
• A -_q_-shaped flag (an expandable string used as a flag name) doesn't get treated as -Value (name comparison requires va*, not matched), so it doesn't wrongly exempt a following real value — over-block direction only, not a security gap.

Not independently executed: pwsh is present in this sandbox, but invoking it (and invoking the test scripts) required approval that wasn't available this run, so — consistent with every prior review round on this branch — my confirmation is a static trace of the tokenizer logic against the new test's exact command text, not a dynamic run.

Other angles re-checked, no new issues:

• The interrogation-ok sink-scope wiring, the git-token allowlist walk, and the remote/stash argument-aware carve-outs are unchanged from prior rounds and still hold.
• No GitHub Actions/workflow files touched by this PR.
• No other secrets/credential handling touched; the other 7 files in this PR's change set are unchanged since the last review pass.

This closes the open CRITICAL thread from the earlier rounds on this branch — I have no further findings blocking this PR on security grounds.

[claude]

Code review (correctness & maintainability) — /review:code-review

• Gather context (PR body, prior review comments, diff)
• Invoke /review:code-review skill and follow it exactly for this PR (HEAD af771d6)
• Post findings

View job run

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 557b7e6b09

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[claude]

Claude finished @kyle-sexton's task in 3m 17s —— View job

---

Security review complete

• Gather context (PR body, prior review comments, diff)
• Invoke /review:security-review and follow it exactly for this PR (repo melodic-software/claude-code-plugins, PR fix(guardrails): allow read-only git inside PowerShell grouping #5548, HEAD 5a3e6c7)
• Confirm plugins/guardrails/lib/powershell/ps-command.sh is unchanged since the last cleared HEAD (af771d6) — only a comment-only portability-exemption tweak to block-dangerous-git.test.sh and unrelated origin/main merge content landed since
• Re-verify the Codex P2 finding posted after that last review (native env wrapper setting GIT_*) by statically tracing it through ps::has_unprovable_env_write and ps::git_command_is_interrogation_only
• Post findings

1 CRITICAL finding (unresolved carry-forward, new technique), posted inline on ps-command.sh#L1903-L1913:

ps::has_unprovable_env_write's command-word dispatch doesn't recognize a native env wrapper as an environment write. This is the identical GIT_PAGER/GIT_EXTERNAL_DIFF RCE class every prior round on this PR flagged, reached through a route the syntax-based rewrite (daee34b/2b63cb9) never considered — a coreutils-style env NAME=VALUE cmd invocation instead of Env:/$env:/[Environment]:

& { env GIT_EXTERNAL_DIFF=C:\tools\mutator.exe git diff --ext-diff }

I traced this line-by-line (full walkthrough in the inline comment): env matches none of the case arms in ps::has_unprovable_env_write (falls to the catch-all *) ;;, so write_head/dyn_cd never set), isn't a recognized launcher (ps::has_launcher's list omits it), and the GIT_EXTERNAL_DIFF=... assignment tokenizes apart from the real git token cleanly enough that the git-token walk's boundary checks don't flag it either. git diff is on the interrogator allowlist with no argument constraint, so the whole statement classifies interrogation-ok and block-dangerous-git (wired at block-dangerous-git.sh lines 1405/1468) lets it through. At execution, GIT_EXTERNAL_DIFF runs the attacker's binary as git's external-diff helper — the same technique works for GIT_PAGER via & { env GIT_PAGER=C:\evil.exe git log }.

This was independently flagged by Codex as a P2 on commit 557b7e6, after the last Claude security-review pass had already cleared that same HEAD. Since neither review addressed it and ps-command.sh hasn't changed since, it's a live, untested gap — no case in block-dangerous-git.test.sh covers an env-prefixed or other non-PowerShell environment-setting wrapper. It does depend on an env executable being resolvable on PATH, which isn't a PowerShell built-in, but is a routine presence on exactly the developer machines this plugin's PowerShell guardrails target (Git for Windows' usr\bin, WSL interop, MSYS2/Cygwin, coreutils via scoop/choco).

Other angles re-checked, no new issues:

• The interrogation-ok sink-scope wiring, the git-token allowlist walk, the remote/stash argument-aware carve-outs, and the location-change fix (2b63cb9) all remain correct against the adversarial set prior rounds validated.
• No GitHub Actions/workflow files touched by this PR.
• No other secrets/credential handling touched; the other 9 files in this PR's change set carry only version-bump/changelog/README churn and a single comment-only test annotation since the last review pass.

Not independently executed: command execution in this sandbox requires approval this session doesn't grant (consistent with every prior review round on this branch) — this is a static trace of the tokenizer logic against the exact PoC text, not a confirmed dynamic run through real pwsh.

[claude]

Claude finished @kyle-sexton's task in 1m 22s —— View job

---

Code review (correctness & maintainability) — /review:code-review

• Gather context (PR diff, prior review comments on this branch)
• Determine what changed since the last completed code-review-lane pass (commit e51802c/daee34b, 2026-09-30T18:36:21Z) — one real content commit, f58520c, plus two origin/main merges
• Review the new content for correctness and maintainability
• Post findings

No correctness or maintainability findings.

The last completed pass from this lane reviewed e51802c (commit daee34b,
the syntax-based ps::has_unprovable_env_write rewrite) with no findings. A
code-review-lane run fired again at that same round (af771d6) but never
finished posting output, so I independently re-diffed this PR's 10-file
change set between af771d6 and the current head 5a3e6c7 rather than
trust that gap.

Only one real content commit landed since e51802c: f58520c
("record the Windows module-path literal as portability-exempt"), a one-line
change to
block-dangerous-git.test.sh:1370,
appending a trailing # portability-ok: a Windows module-path separator in the command under test, not a GNU grep word boundary annotation to an
existing pin_predicate line, no logic change. I checked this against the
portability-ok: <reason> convention already used throughout the codebase
(lib/hook-utils.sh, scripts/hook-census.sh,
scripts/check-guardrails-ps-differential.sh, docs/plugin-philosophy.md:360)
— the marker, placement (trailing comment on the flagged line), and wording
match that convention exactly, so this correctly resolves what was presumably
a shell-portability gate false positive on the \\ in
Microsoft.PowerShell.Management\Set-Content.

The rest of the diff since af771d6
(plugin.json, CHANGELOG.md, README.md) is version-bump/changelog
renumbering from the two origin/main merges (main's own 0.44.0
SessionStart-node-missing entry interleaved ahead of this PR's 0.43.4→now
0.44.1 bump) plus one README wording tweak (hook row → guard row)
carried in from main's own commit — not new content from this PR's author.
No file in ps-command.sh, block-dangerous-git.sh, block-no-verify.sh,
block-no-verify.test.sh, block-convention-violation.sh, or
block-noncanonical-commit.sh changed in this range, so the prior rounds'
resolved findings (the Set-Location named-parameter bypass fixed by
2b63cb9, the README gap fixed earlier) still stand as-is.

Note on the open security thread: the security lane's last pass on this
branch (af771d6, 2026-09-30T19:24:38Z) closed its previously-open CRITICAL
finding with "I have no further findings blocking this PR on security
grounds." Whether that still holds at this head is that lane's call — the
ps-command.sh logic it reviewed is byte-for-byte unchanged since then, per
the diff stat above.

Not independently executed: I did not run the shell test suites in this
sandbox; author-claimed verification (affected-tests.sh, shellcheck,
changelog-parity checks) is unverified by me, consistent with prior passes on
this branch.

[claude]

Claude encountered an error after 5m 16s —— View job

---

Security review in progress

• Gather context (PR body, prior review comments, diff)
• Invoke /review:security-review and follow it exactly for this PR (repo melodic-software/claude-code-plugins, PR fix(guardrails): allow read-only git inside PowerShell grouping #5548, HEAD 5cb25f3)
• Post findings

[claude]

Claude finished @kyle-sexton's task in 2m 35s —— View job

---

Code review (correctness & maintainability) — /review:code-review

• Gather context (PR diff, prior review comments on this branch)
• Determine what changed since the last completed code-review-lane pass (commit 5a3e6c7) — one real commit, 5cb25f3 "refuse a native env wrapper beside a read-only git group"
• Review the new env case arm in ps::has_unprovable_env_write for correctness/maintainability
• Review the new test cases and CHANGELOG entry
• Post findings

1 finding, posted inline on ps-command.sh:1841:

The header doc comment for ps::has_unprovable_env_write (the "ways a command reaches the environment" list, lines 1815-1841) wasn't updated for the new env/env.exe case arm added at line 1907. CHANGELOG.md documents the addition and the code implements it, but the function's own doc comment — which earlier rounds on this PR already relied on and twice flagged as needing to stay in sync (the README.md:197 bullet, and this header's item "d") — omits it. A reader consulting only this comment wouldn't learn that a native env wrapper beside the read-only git group is refused.

What I checked, no other issues found:

• The new case arm (env | env.exe | */env | */env.exe | *\\env | *\\env.exe) sits in the case "$head" in dispatch inside ps::has_unprovable_env_write, matching against the lowercased, quote-opaqued command-word token — correctly catches a bare env/env.exe word as well as a path form (/usr/bin/env, C:\Tools\env.exe), consistent with the four new run_pwsh-executed test cases in block-dangerous-git.test.sh (lines covering GIT_EXTERNAL_DIFF, GIT_PAGER, a Unix path, and a Windows path), which exercise the real hook rather than a predicate pin.
• The CHANGELOG bullet update accurately describes the new behavior and is consistent with the code.
• No other file changed in this commit; the rest of this PR's 10-file change set is unchanged since the last code-review-lane pass (5a3e6c7).

Note on the open security thread: whether this fix fully closes the class the security lane flagged (a coreutils-style env wrapper reaching GIT_PAGER/GIT_EXTERNAL_DIFF without touching Env:/$env:/[Environment]) — and whether any related bypass remains, e.g. via a quoted command word — is that lane's call, not this one's; I did not duplicate that adversarial analysis here per this lane's security-findings scoping rule.

[claude]

Claude finished @kyle-sexton's task in 42s —— View job

---

Code review (correctness & maintainability) — /review:code-review

• Gather context (PR diff, prior review comments on this branch)
• Determine what changed since the last completed code-review-lane pass (commit 5cb25f3) — one commit, a69059e "docs(guardrails): list the native env wrapper in the env-write scan header"
• Review the new content for correctness and maintainability
• Post findings

No correctness or maintainability findings.

The last code-review-lane pass on this branch (2026-09-30T20:32:19Z) reviewed commit 5cb25f3 (which added the env/env.exe command-word case arm to ps::has_unprovable_env_write) and flagged one maintainability gap: the function's own header doc comment wasn't updated to list that new case, even though the CHANGELOG entry for this bump already described it.

The only commit since then, a69059e (current HEAD), is exactly that fix — a 3-line, comment-only addition to the header doc comment:

+#   - a native `env` or `env.exe` command word, bare or by path, which sets the
+#     named variables for the command it runs: the write spelled as program
+#     arguments instead of a provider path;

(ps-command.sh#L1841)

I confirmed via git diff 5cb25f3 a69059e that this is the only change in the commit — no other file, and no line of actual logic, moved. The new bullet's wording matches both the CHANGELOG's 0.44.1 entry and the case arm's own inline comment (ps-command.sh#L1905-1907) accurately: it correctly scopes the refusal to a native env/env.exe command word (bare or by path), consistent with the four run_pwsh-executed regression tests 5cb25f3 added (GIT_EXTERNAL_DIFF, GIT_PAGER, a Unix path, a Windows path). Placement (appended before the closing $( ... ) bullet and the "Not seen" note) matches the list's existing structure.

No other file in this PR's 10-file change set moved since the last review pass.

Note on the open security thread: this commit is documentation-only and doesn't touch review logic, so it has no bearing on the security lane's open findings — not duplicating that analysis here per this lane's scoping rule.

[claude]

Claude finished @kyle-sexton's task in 2m 12s —— View job

---

Security review complete

• Gather context (PR body, prior review comments, diff)
• Invoke /review:security-review and follow it exactly for this PR (repo melodic-software/claude-code-plugins, PR fix(guardrails): allow read-only git inside PowerShell grouping #5548, HEAD a69059e)
• Re-verify the env-wrapper fix (5cb25f3) against the CRITICAL finding it addresses, and hunt for a bypass of the fix itself
• Post findings

No security issues found.

What changed since the last reviewed HEAD (5a3e6c7, which had an open CRITICAL finding): two commits, 5cb25f3 ("refuse a native env wrapper beside a read-only git group") and a69059e (doc-only header comment addition, 3 lines, no logic change — confirmed via git show --stat a69059e). No other file in this PR's 10-file change set moved.

The fix. 5cb25f3 adds a case arm to ps::has_unprovable_env_write (ps-command.sh#L1910):

env | env.exe | */env | */env.exe | *\\env | *\\env.exe) return 0 ;;

This closes the CRITICAL gap the prior review round flagged and Codex independently flagged as P2 on 557b7e6: a coreutils-style env NAME=VALUE cmd wrapper (& { env GIT_EXTERNAL_DIFF=C:\tools\mutator.exe git diff --ext-diff }) previously matched none of the recognized write heads, so it slipped through classified interrogation-ok.

I traced the fix against the exact PoC from that finding and against bypass attempts of my own:

• The original PoC (& { env GIT_PAGER=... git log }, & { env GIT_EXTERNAL_DIFF=... git diff --ext-diff }): the command word env (bare, */env, */env.exe, *\env, *\env.exe — covering both path separators and the .exe suffix) now unconditionally returns 0 (write found) regardless of what follows, so block-dangerous-git refuses it. Confirmed against the four new run_pwsh-executed test rows in block-dangerous-git.test.sh:1036-1039 (GIT_EXTERNAL_DIFF, GIT_PAGER, a Unix path, a Windows path).
• Quoting the command word to dodge the literal env match (& { & 'env' GIT_PAGER=... git log }): this doesn't reach the case statement as a bypass — ps::call_target_is_bare_computed/ps::has_dynamic_invocation (ps-command.sh line 2146, [.\&][[:space:]]*['"]) already matches & or . immediately followed by a quote character, so this is independently caught earlier in ps::git_command_is_interrogation_only (ps::has_dynamic_invocation "$1" && return 1) and refused. PowerShell also doesn't allow a bare quoted string as a command head without the &/. call operator, so there's no quoting route that skips both checks.
• Other launcher-style env-setters (cmd /c "set X=Y && ...", wsl env ...): already caught by ps::has_launcher (unchanged), which routes the whole command to the fail-closed sink rather than relieving it.
• Case sensitivity, UNC paths (\\server\share\env.exe), and ./env all fold correctly through the existing lowercasing and glob patterns.

I did not find a bypass of this fix, and no other file changed in this range that would reopen it.

Other angles re-checked, no new issues:

• The interrogation-ok sink-scope wiring, the git-token allowlist walk, the remote/stash argument-aware carve-outs, the location-change fix (2b63cb9), and the rest of ps::has_unprovable_env_write's write-detection cases are unchanged since the last cleared review pass and still hold.
• block-no-verify.sh's readonly-ok scope calls a separate, unchanged classifier (ps::git_command_is_readonly) and doesn't go through ps::has_unprovable_env_write, so it's unaffected by and out of scope for this fix.
• No GitHub Actions/workflow files touched by this PR.
• No other secrets/credential handling touched.

Not independently executed: command execution in this sandbox requires approval this session doesn't grant (consistent with every prior review round on this branch) — this is a static trace of the tokenizer logic against the exact test/PoC text, not a confirmed dynamic run through real pwsh.

This closes the last open CRITICAL thread on this branch — I have no further findings blocking this PR on security grounds.