fix(guardrails): shared parser conflates --config-env values with -c values

[kyle-sexton]

Problem

hook::bash_parse_segments' git-option walk records -c, --config, and --config-env values into the same HOOK_GIT_CONFIG_VALUES array with no marker distinguishing them (hook-utils.sh:796-801).

They are not the same thing. -c alias.c=commit supplies the value commit; --config-env=alias.c=VAR supplies the name of an environment variable holding the value. A consumer reading the array cannot tell them apart, so it treats VAR as the alias expansion.

Impact

Both git guards inherit this, and both currently fail open on it:

• block-noncanonical-commit — git --config-env=alias.z=AV z -m x (with AV=commit) is not recognized as a commit. Verified exit 0.
• block-dangerous-git — same shape for its alias expansion path.

Neither is a correctness bug in the guards themselves; the information they need is not in the array.

Fix sketch

Tag the origin in the shared parser — e.g. a parallel HOOK_GIT_CONFIG_VALUE_KINDS array, or an env: prefix on --config-env entries — then have each consumer resolve an env-sourced value from the hook's inherited environment. An inline env-assignment prefix on the command line (AV=commit git --config-env=...) stays out of scope: the parser does not evaluate shell assignments, which is an already-documented residual.

Why not fixed in #736

It is a hook-utils.sh change shared by both guards, with its own test surface. #736 documents the residual in the new hook's header rather than half-fixing it in one consumer.

Related

• Refs feat(guardrails): block non-canonical git commit; fix trailer-policy false positive #731 / feat(guardrails): block non-canonical git commit; drop --trailer conjunct #736 — where this surfaced.

[kyle-sexton]

This was generated by AI during triage.

Severity note for sub-sort (rule 5): this is a fail-open gap in a security guardrail (both block-noncanonical-commit and block-dangerous-git can be bypassed via --config-env) — higher urgency within the medium tier than a typical mechanical fix, even though it doesn't meet the rule 5/8b/8c criteria for priority: high. No open design decision — the fix sketch already names the concrete approach (tag origin in the shared parser, resolve env-sourced values from the hook's inherited environment).

[kyle-sexton]

Claimed by tower overnight worker, 2026-07-21 ~10:0xZ. Implementing the shared-parser fix in hook-utils.sh (hook::bash_parse_segments): tag the origin of -c/--config/--config-env values so consumers can distinguish an inline value from an env-var name, then have block-noncanonical-commit and block-dangerous-git resolve env-sourced values from the hook's inherited environment. Inline shell env-assignment prefixes stay out of scope (documented residual). Will add per-parser + per-guard test coverage.

[kyle-sexton]

[kyle-sexton]

Released claim — cross-actor collision detected: PR #903 (closing this issue) already has substantial work predating this cycle's pick (first commit 2026-07-21T18:14:09Z, hours before this lane claimed #740 at ~23:17Z). Standing down my dispatched worker's independent, unpushed, now-redundant fix rather than racing or patching a branch I don't own. #903 is already correctly do-not-merge gated with the one remaining confirmed finding documented on the PR via its own review passes — leaving it to its owner.