fix(guardrails): block-hook-bypass exempts a quoted redirect target on its first word only

[kyle-sexton]

block-hook-bypass.sh decides its target-based exemptions on the first whitespace-delimited word
of a quoted redirect operand, not on the operand. strip_literals deliberately keeps a quoted
write target as literal content — dropping the quotes so a quoted target still reads as a write — and
_redir_scan's target class terminates at whitespace. A quoted target containing a space therefore
resolves, for exemption purposes, to its first word.

Today that reaches the /dev/null exemption. It is the same shape the guard's own comment at
:465-472 was written to prevent for a different input (redirect ordering), and it is the one
target-word assumption that comment does not cover.

Rows

• plugins/guardrails/hooks/block-hook-bypass.sh — strip_literals (open_keep, the quoted
  redirect-operand branch) and _redir_scan (the target class ending at whitespace) — a quoted
  redirect operand containing whitespace is exempt-tested on word 1 only.

Evidence

Measured at repo HEAD 685dd381, hook invoked as a decision function on a PreToolUse Bash payload
(rc=2 blocked, rc=0 allowed):

rc=0 :: echo x > "/dev/null ../../etc/pw"        # exempted on the word `/dev/null`
rc=2 :: echo x > "/tmp/scratch/a ../../etc/pw"   # control: no exemption applies, so it blocks

The first is the defect: the operand is one word to the shell, and nothing named /dev/null is the
write destination, yet the discard exemption fires.

_redir_scan, plugins/guardrails/hooks/block-hook-bypass.sh:294:

_redir_scan=$'(^|[^0-9&])1?>>?[[:space:]]*([^|&>[:space:]\x01\x02]+)'

and the kept-operand rule the quotes are dropped by, :127-130:

  # `open_keep` carries, alongside it, whether that span is a REDIRECT OPERAND (a quoted
  # target: the char before the opening quote is `>`) — those are kept as literal
  # content instead of dropped, so a quoted write target survives the strip.

Exploitability, stated honestly

Reaching a chosen file this way needs a directory whose name ends in the whitespace-bearing
fragment (/dev/null .. above) to already exist, so this is a correctness and
defence-in-depth defect rather than a demonstrated escape. It matters because it is the exact
assumption a target-based exemption rests on, and the guard has one such exemption today and a second
(opt-in) one landing in #2210.

Why this is filed rather than fixed in #2210

Discovered while building the scratch-root exemption (#2210) and confirmed to pre-date it — the
/dev/null half reproduces on origin/main at 685dd381, before any of that work. Recovering it
needs strip_literals to mark a kept operand's internal whitespace with a sentinel, which is shared
machinery every lane of the guard reads and which #1680 and #1667 also concern. That is a wider
change than a single carve-out row should carry. PR #2224 documents the residual in the file, the
README and the CHANGELOG, and pins both halves (the scratch target and the /dev/null control)
with accepted-floor tests, so a fix here flips them together and visibly.

Adjacent

• fix(guardrails): block-hook-bypass blocks scratch-file writes in read-only work — no target-path carve-out beyond /dev/null #2210 / PR feat(guardrails): opt-in scratch-root exemption for block-hook-bypass write targets #2224 — the scratch-root exemption that surfaced this; documents and pins it.
• fix(guardrails): block-hook-bypass wrongly blocks echo/printf ... >&N as a file-write bypass #1680 (critical), block-hook-bypass.sh:375 — patsub_replacement (Bash 5.2+) silently disables the >&N sentinel restore, false-positives on bare echo/printf >&2 #1667 — other defects in the same normalization/sentinel machinery; a fix
  should be coordinated with them.
• guardrails: hooks ship false-positive over-fires with no per-hook fixtures or shared precision convention (6-issue class: diff-scope, quoted-arg, boolean-intent, stdin, path-branch) #547 — the guard-precision class issue.

Provenance

Severity: MED · Provenance: reproduced at repo HEAD 685dd381 by the batch-4 lane that found it;
no independent auditor pass — this row originates from implementation work, not from a ledger.
Origin: discovered during handoff-inbox batch 4, lane C, while implementing
.work/handoff-inbox-batch-4/ledgers/I5-claude-ops-guardrails-unverified.md § F2b (#2210).
Verified against repo HEAD 685dd381.

[kyle-sexton]

Scope update from PR #2224 (which surfaced this).

Review on that PR sharpened the shape: the truncation is not only whitespace. normalize_segments turns a ;, |, & or newline inside a quoted operand into a segment boundary, so all of these are exempted on the prefix /dev/null at HEAD 685dd381:

rc=0 :: echo x > "/dev/null;/../../etc/passwd"
rc=0 :: echo x > "/dev/null|/../../etc/passwd"
rc=0 :: echo x > "/dev/null ../../etc/pw"

PR #2224 does not fix this — it makes its own new scratch-root exemption fail closed on any quote or backslash after the first redirect operator, and pins the /dev/null half above with a control test that flips visibly when this issue is fixed. So the remaining work here is exactly the /dev/null arm, and the real fix is in strip_literals: a kept redirect operand's internal separators need marking so the segment split cannot consume them. That is shared machinery #1680 and #1667 also read.

[kyle-sexton]

Further evidence, from review on #2235: the missing operand/quote association bites a second consumer, not just the target extraction.

The scratch-root fail-close added in 0.25.0 has to read the raw command, and it splits it with ${COMMAND#*>} — the first literal > character, with no way to tell whether that > is syntax or content. So a > inside quoted content starts the scanned tail early:

rc=2 :: echo "a > b" > /tmp/scratch/f     # the closing quote of "a > b" lands in the tail
rc=2 :: echo 'x > y' > /tmp/scratch/f
rc=0 :: echo "hello world" > /tmp/scratch/f

Same for segment scope: echo x > /tmp/scratch/f && grep foo "notes.txt" blocks on a quote belonging to an unrelated later command.

Both are the safe direction — the check can only refuse an exemption, never grant one — so #2235 documents and pins them rather than attempting a fix. But they are the same root cause as this issue from the other side: the target extraction loses which separators are syntax, and any consumer reading the raw command loses which > and which quotes are syntax. A strip_literals change that marks a kept operand's internal separators would let both this issue's /dev/null arm and #2235's fail-close become precise instead of blunt.

Worth weighing when this is scheduled alongside #1680 and #1667.