guardrails: ps::blank_quoted_spans deletes quoted operands, so quoting evades the computed-call positional write signal

[kyle-sexton]

Problem

ps::blank_quoted_spans (plugins/guardrails/lib/powershell/ps-command.sh:163) deletes quoted spans outright:

text=$(printf '%s' "$text" | sed -e "s/'[^']*'//g" -e 's/"[^"]*"//g')

Every probe downstream therefore sees a quoted operand as absent, not as present-but-opaque. For ps::computed_call_has_positional_write_signal, whose two-positional arm requires at least one visible literal operand, that means quoting an operand removes it from the count entirely — so quoting is a general evasion of the positional write signal.

Evidence

Executed against origin/main at 4e6249ae77335f8786b4ae36d0888073569c27a0 and against the pre-merge base 10bdd7c5127409fbe70026cec923d17e8bfd8c20, each command fed as a real PreToolUse PowerShell payload built by jq (no shell quoting touched the command string), rc from block-hook-bypass.sh:

command	base 10bdd7c5	main 4e6249ae7
& $w f.txt x (unquoted control)	rc=2	rc=2
& $w 'f.txt' 'x'	rc=0	rc=0
& $w 'f.txt' x	rc=0	rc=0
& $w (Join-Path $d f.txt) 'x'	rc=2	rc=0

The first three rows are rc=0 on both sides: this is a pre-existing residual, not something PR 2890 introduced. It is filed separately for exactly that reason.

The fourth row did change, but not because the quoting behavior changed. It blocked on base only because the blanket ps::has_special_constructs arm was catching the (/) grouping — the incidental over-block that issue 2848 exists to remove. Once that arm went, the row fell through to the positional probe and hit the same pre-existing quoted-operand blindness the rows above document. So the underlying defect is unchanged; PR 2890 only made one more shape reach it.

Why the current behavior is wrong

& $w 'f.txt' 'x' is a complete Set-Content <path> <value> call through a computed target. It is the exact Path+Value shape the #2722 positional signal exists to catch, and quoting the operands — the more idiomatic PowerShell spelling, not an obscure one — makes it invisible.

Suggested direction (not prescriptive)

Replace a quoted span with a placeholder token rather than deleting it, so the operand still counts as one visible literal while its content stays opaque. This must be scoped carefully: ps::blank_quoted_spans feeds many probes, and several depend on the deletion semantics (a quoted > or -value in message text must stay inert). A contained option is to derive a separate placeholder-preserving string inside ps::write_bypass and hand only that to ps::computed_call_has_positional_write_signal.

Over-block risk that must be measured before shipping

A placeholder makes quoted operands count, so & $py "script.py" "arg" would begin to block. That is consistent with today's & $py script.py arg (already rc=2), but it is a real behavior change and needs its own probe table across all three blocking hooks, plus the acceptance cases from issue 2848:

• & $py $script (Join-Path $dir "$id.jsonl") must stay rc=0
• $py = "..."; if (-not (Test-Path $py)) { ... }; & $py C:/s/run.py --flag must stay rc=0
• & $py -m unittest discover, . $PROFILE, & $py script.py must stay rc=0

Provenance

Surfaced by the fresh-context verifier agent on PR 2890 (issue 2848) while adversarially probing merged content. The verifier's other finding — a braced call target (& ${env:w} …) matching no call site — was a regression from that PR and is fixed separately. This one is recorded as the pre-existing residual it is.

[kyle-sexton]

Measured evidence and a recommendation — awaiting an operator decision, deliberately not implemented

A dedicated lane measured this issue's suggested direction (placeholder token instead of deletion) plus a global variant, with a fresh-context verifier independently executing every probe in its own worktree. The verifier's numbers matched the worker's on every row, with zero disagreements. Recording the result here so the decision does not live only in a chat transcript.

Recommendation: take the CONTAINED variant, sequenced behind issue 2965. Not implemented, because the deletion-to-placeholder change is a semantics change several probes depend on, which is an operator call rather than something to fold in behind a merge.

Containment is confirmed

Across 52 probe rows, block-dangerous-git and block-no-verify exit codes are identical between base and the contained variant — 0 diffs in 52 rows each. Every one of the 10 diffs in the entire matrix lands in block-hook-bypass. That is the strongest evidence in the dataset for a contained change over a global one.

• All six issue-2848 acceptance cases stay rc=0 on all three hooks.
• All five open bypass shapes close, including & $w 'f.txt' 'x' and & $w 'f.txt' x.
• The unquoted control was already closed on base.

The global variant is confirmed dead

Four producer-redirect rows go fail-OPEN under it, including a redirect of an interpolated environment variable into a file. There is also a boundary-adjacency fail-open that the obvious repair does not fix. Do not pursue the global form.

The real decision is a framing disagreement, not the mechanics

The worker and its own verifier read the same numbers two defensible ways:

• Worker's framing: quoting stops being a free escape hatch from the positional write signal — a real bypass class closes.
• Verifier's framing: base already over-blocks & $npm run build at rc=2, which writes nothing. The contained variant does not introduce asymmetry; it doubles that existing over-block's footprint by extending it to quoted forms.

Both are true of the same measurements. If & $exe 'sub' 'arg' is judged wrong to block in the first place, the right sequencing is to narrow that signal before making it reach further. That is the judgement call this issue is parked on.

Sequencing is forced, not preferred

Independently re-measured against pristine 6dc12e45a:

Write-Host "it's fine"; & $w 'f.txt' 'x'     block-hook-bypass = 0
ps::blank_quoted_spans returns:  Write-Host "itf.txtx'

The apostrophe inside the double-quoted string pairs with the opening quote of 'f.txt' and destroys the call site outright. No fix for this issue can see that command until issue 2965 lands. Ordering is not a preference.

One prototype bug to fix before any implementation

In the contained variant's helper, the interpolated-string rule is evaluated before the dash-flag rule, so a token that both starts with - and contains $ (for example "-Path$x") classifies as a computed operand rather than a flag. No row in either table exercises it. The dash rule must be ordered first.

If a cold agent picks this up

Do not implement until an operator has chosen between the two framings above. When approved: land issue 2965 first, fix the rule ordering, then implement the contained variant only — deriving a placeholder-preserving string inside ps::write_bypass and handing it to ps::computed_call_has_positional_write_signal alone, never changing ps::blank_quoted_spans globally. Re-run the full 52-row matrix plus the six issue-2848 acceptance cases across all three hooks, with negative controls that must exit 2, and pair it with a fresh-context verifier that executes the probes itself.

Related

• issue 2965 — the entry-side defect in the same function that blocks this one.
• issue 2848 — the acceptance cases any change here must preserve.

[kyle-sexton]

Claimed by lane cursor/2906-quoted-operands-cfcf: contained placeholder for quoted operands in ps::computed_call_has_positional_write_signal only. #2965/#2984 already on main.