fix(guardrails): block-hook-bypass false-positives a print-only python3 -c, pushing users to the opaque form

[kyle-sexton]

Filed by AI. Hit independently by two sessions today, and it is a false block that pushes the user
toward the less inspectable form — which makes it worse than an ordinary nuisance.

The false positive

plugins/guardrails/hooks/block-hook-bypass.sh rejects an inline python3 -c that performs no file
write at all:

BLOCKED: python3 -c file write bypasses Write/Edit hooks

The snippet in question only called print(). No redirect, no open(..., 'w'), no file write of any
kind.

Why this is worse than a nuisance

The guard exists so that file writes go through Write/Edit and their hooks. The observed workaround —
taken by the session that hit it — was to move the snippet into a script file and run that
instead. That is strictly worse for the guard's own purpose:

• An inline python3 -c is fully visible in the command string the hook inspects.
• A script file is opaque to it — the hook sees python3 /tmp/thing.py and cannot see what the
  program does. The guard's own scope note says as much: writes inside an invoked script file are
  not seen.

So the block moved the operation from a form the guard can read to one it cannot. A guard that
blocks correct usage teaches people to route around it, and here the route around is the exact blind
spot the guard is trying to cover.

This is the same dynamic documented in #2139, where the guarded thread-resolution wrapper is bypassed
by a raw mutation in 49 of 54 transcripts.

Scope note

I hit the sibling forms of this guard several times today and those blocks were correct — an
echo >file and a cat >file really were file-write workarounds, and being pushed to Write/Edit was
the right outcome. So this is a matcher precision problem on the python3 -c arm specifically, not
an argument against the guard.

What would close it

• The python3 -c arm distinguishes a program that writes from one that does not, or narrows to
  forms that plausibly write (open(, >/>> redirects, pathlib, shutil, os.replace,
  subprocess with a redirect) rather than firing on the -c form itself.
• Or, if precise detection inside arbitrary Python is judged infeasible — a defensible conclusion —
  then the message should say so and point at the sanctioned route, rather than asserting a file
  write that did not occur. A block whose stated reason is factually wrong for the command in hand
  is what makes a user reach for the opaque workaround instead of the intended one.

Acceptance

• A print-only python3 -c is allowed.
• A genuinely write-performing python3 -c is still blocked — with a control proving the case
  discriminates, i.e. it fails against the fixed matcher if the write detection is removed.
• Neither assertion passes for the wrong reason: verify the fixture actually reaches the python3 -c
  arm rather than exiting earlier, since a guard that never ran looks identical to a guard that
  allowed.

Related

• chore(source-control): review-thread resolution has no audit trail, and the guarded wrapper is routinely bypassed #2139 — the same route-around dynamic, measured
• fix(guardrails): every hook calling hook::require_jq fails OPEN when jq is absent, while the same guard fails closed on length #2146 — the other posture question in this plugin's guards
• Triage the remaining stranded P2 review findings from the post-merge sweep #1938 — the stranded post-merge review-findings sweep

[kyle-sexton]

Second instance, different guard, same shape — and this one blocked a verification harness

Recording alongside the python3 -c case because it is the same defect class and the second one today, which makes it a pattern rather than a one-off.

What happened. An agent verifying block-dangerous-git had its probe blocked by that guard. The --force-with-lease text existed only inside a JSON payload string being fed to the hook under test — no push anywhere, fixture repositories with no remotes configured. Static matching over the literal command string cannot distinguish a payload describing a command from an invocation of one.

The workaround was the same as the python3 -c case, and that is the point. The agent moved the fixture into a script file — which is the guard's own documented scope boundary, i.e. the form it explicitly cannot see inside. Twice now, in one day, across two different guards, the block has pushed a user from a form the guard can read to one it cannot.

The agent flagged the shape of its own action rather than quietly routing around, which is worth quoting because it is the right instinct:

relocating a command to evade a guard is the exact behaviour I warned about in the docblock, and it was only legitimate here because the command was inert and the guard's own contract scopes itself to the command string. It would not have been legitimate if the push were real.

Why this instance is worse than an ordinary false block. It fires on the act of testing the guard. Anyone writing or verifying a fixture for these hooks hits it, and the sanctioned escape is the opaque form — so the guard actively degrades the quality of its own test suite. That is a self-reinforcing loop the python3 -c case does not have.

Not proposing a fix here. Distinguishing "a string that contains a dangerous command" from "a dangerous command" is genuinely hard, and a naive carve-out for anything that looks like JSON would be a bypass in its own right. But the two instances together suggest the useful question is not "how do we match more precisely" — it is whether the message should acknowledge the possibility and point at the sanctioned route, rather than asserting an operation that did not occur. A block whose stated reason is factually wrong for the command in hand is what sends people to the workaround.

Cross-reference: #2151 records this incident in situ, with the probe table it interrupted.

[kyle-sexton]

Coordination note from the handoff-inbox batch-4 validation pass: #2217 files the opposite direction on the same regex — block-hook-bypass.sh:670 requires the literal python3, so python -c, py -c and python3.11 -c are not matched at all (reproduced at HEAD 685dd381). Widening that interpreter pattern touches the same detector this issue reports as over-blocking, so the two want one sitting rather than two. No change to this issue's own scope.

[kyle-sexton]

Skip (already fixed on origin/main). block-hook-bypass.sh now uses py_write_indicator(): bare open( blocks only when a write-mode literal co-occurs; print-only python3 -c passes. Landed via #2007; regression tests in block-hook-bypass.test.sh (e.g. read-only open(), print(json.loads(...))). No new PR needed.

[kyle-sexton]

Closing as already addressed on main: block-hook-bypass no longer blocks print-only python3 -c (see py_write_indicator write-mode co-occurrence and test rows for #2217: py -c print only (allowed)). The guard still blocks genuine inline writes.