fix(guardrails): block-hook-bypass producer detection misses three inline-write forms (one a documented accepted residual)

[kyle-sexton]

Three inline-write forms reach a real file through block-hook-bypass.sh without matching any
detector. All three sit in the guard's own declared threat model (inline interpreter code, and a
producer whose stdout is redirected into a file), so they are gaps in something already modeled
rather than new scope. One of them is a documented accepted residual, not an oversight — see its
row.

The guard is explicitly "a speed bump … not a boundary", so none of these is critical. What makes
them worth one issue is that the interpreter arm interacts: widening the interpreter pattern touches
the same regex that #1601 and #2148 report as over-blocking, so all of it wants one sitting.

Rows

• I7 C-H1 — plugins/guardrails/hooks/block-hook-bypass.sh:670 — the Bash-lane interpreter
  detector requires the literal python3, so python -c, py -c and python3.11 -c all pass. The
  same floor exists in the PowerShell lane's ps::might_write_via_python3 (invoked at :638).
• I7 C-H3 — plugins/guardrails/hooks/block-hook-bypass.sh (strip_literals /
  normalize_segments) — a producer whose quoted content spans a physical newline is split from
  its own redirect: the strip carries the open quote span across lines but re-emits the newline,
  normalize_segments splits on \n, and producer_redirect_bypass requires producer and redirect
  in one segment.
• I8 G1 — plugins/guardrails/hooks/block-hook-bypass.sh:670-673, residual documented at
  :635-636 — a stdin heredoc (python3 - <<'PY' … PY, no -c) is uncovered. This is a
  documented accepted residual, not an unrecognized gap. File/treat it as reopening an accepted
  residual on new reachability evidence: a session hit it while trying to comply with the guard's
  own remediation. A fix that lands here must update the acceptance comment, not contradict it.

Evidence

C-H1, reproduced at HEAD (payloads built with jq -n --arg, piped to the hook; rc=2 blocked,
rc=0 allowed):

rc=2 :: python3 -c "open(\"f\",\"w\").write(\"x\")"
rc=0 :: python -c "open(\"f\",\"w\").write(\"x\")"
rc=0 :: py -c "open(\"f\",\"w\").write(\"x\")"
rc=0 :: python3.11 -c "open(\"f\",\"w\").write(\"x\")"
rc=2 :: echo "*" > .gitignore          # control: the guard is live

block-hook-bypass.sh:670:

if [[ "$EXEC_LC" =~ (^|[[:space:];|&()/\\]+)python3(\.exe)?[[:space:]]+-c ]] &&

Sharpening datum: the guard's own scope note advertises the uncovered spelling as its example.
block-hook-bypass.sh:586-589 — "known shell file-write forms plus recognized inline interpreter
code (e.g. python -c)". The note names the one spelling the regex does not match.

C-H3, reproduced at HEAD:

cmd = $'printf \'a\nb\n\' > notes.md'   → rc=0  (allowed)
cmd = 'printf "a\nb\n" > notes.md'      → rc=2  (blocked)

The discriminator is a physical newline inside the quote span. Mechanism note for whoever fixes
it: emitting a space rather than a newline when a quote span is carried open across a line boundary
is safe, because the span's content is already dropped.

G1, at HEAD block-hook-bypass.sh:670-673 — the detector requires a literal -c; a
python3 - <<PY invocation has none, and neither cat_redirect_bypass nor
producer_redirect_bypass covers it. The acceptance is stated at :635-636:

  # `python3 … -c` + a write indicator in prose, a line/block comment, or a quoted
  # string now blocks; here-string mentions stay inert (blanked first, like the git
  # lane). ACCEPTED RESIDUAL: a stdin heredoc (`python3 - <<PY … PY`, no `-c`) is
  # uncovered here, as it is today.

Adjacent, not duplicate

• guardrails: block-hook-bypass _py_write open( indicator blocks read-only python3 -c reads #1601 (open) and fix(guardrails): block-hook-bypass false-positives a print-only python3 -c, pushing users to the opaque form #2148 (open) — both report block-hook-bypass over-blocking read-only
  python3 -c, the opposite direction. Coordinate: widening the interpreter pattern interacts with
  both.
• guardrails: block-hook-bypass PowerShell lane skips the interpreter-producer scan (python3 -c write bypass) #1199 (closed) — PowerShell lane skipped the interpreter-producer scan; different lane, fixed.
• Inbox 20260723-165339 (status: done, PR fix(guardrails): boundary-anchor _py_write path( indicator (#1178) #1179) — _py_write path( anchoring, a false
  positive on the same hook. Adjacent, already closed.
• Searched "block-hook-bypass heredoc" / "python3 heredoc bypass": zero hits.

Provenance

Severity: MED (cluster max — C-H1 MED, C-H3 LOW, G1 MED)
Provenance: mixed. C-H1 and C-H3 are AUDITOR_VERIFIED and were independently reproduced at HEAD
by the validation pass. G1 is SELF_REPORTED — it has not had an independent auditor pass; only
its code anchor was confirmed at HEAD.
Origin: handoff-inbox items 2026-08-10-plugin-quality-audit-four-components (C-H1, C-H3) and
20260811-021645-routed audit-pass report-path item (G1).
Ledger: .work/handoff-inbox-batch-4/ledgers/I7-four-components-023241Z.md §§ C-H1, C-H3 and
.work/handoff-inbox-batch-4/ledgers/I8-audit-pass-report-path.md § G1.
Verified against repo HEAD 685dd381.

[kyle-sexton]

Implemented in #2367 (guardrails 0.28.0). Three notes for the record.

Anchor drift. This issue was filed before #2287 landed. At 4c90b454 the anchors it cites have
moved: the ACCEPTED RESIDUAL comment is block-hook-bypass.sh:968-969 (not :635-636) and the Bash
lane's interpreter detector is :1005 (not :670). The defects themselves are all still present —
each was re-reproduced against 4c90b454 before any edit — but the line numbers in the body are
stale, so quoting them forward would be a false anchor.

G1 was treated as a reopening, per RECONCILE.md AD-12, not as an oversight. Reachability
evidence established by grep before touching the acceptance:
.work/handoffs/20260809T082720Z-handoff-post-2008-followups.md:211 records a prior session in this
repository reaching for python - <<'PY' to patch a file. (Note the spelling is python, not
python3 — so it is a C-H1 datum as well.) The acceptance comment is updated in both
block-hook-bypass.sh and lib/powershell/ps-command.sh, and the residual is restated at its
narrowed width rather than deleted: python3 <<PY with no - argument stays uncovered, because
matching a bare trailing interpreter token would block echo "pathlib" | python3 and
cat script.py | python3.

C-H3's fix does not use the mechanism the issue suggested. The issue proposes emitting a space
when a quote span is carried open across a line boundary. A space is not sufficient:
ec"<newline>"ho x > f is echo x > f to bash, and a space join leaves ec ho, which
_producer_head does not match — the write is still missed. The join is empty, which is also the
faithful reading (an open quote is what makes the two sides one bash word). That discriminating case
ships as an assertion.

#1601 and #2148 are deliberately not closed. Both were re-verified rc=0 at 4c90b454 — the
write-mode discrimination already fixed the bare-open( mechanism #1601 names — and both repros
are pinned as floors in the new suite, for the widened spellings too, so this change does not reopen
them.