2026-08-15 — iss-200 (env -S guard bypass) fix attempt 2 BLOCKED by two independent reviewers (correctness + security), round stopped per the plugin-user-safety plan's first-attempt-BLOCK STOP. The splice-and-restart approach (`commandOf` re-tokenizes the -S value and re-walks) is REJECTED, not to be re-patched: it introduced a quadratic cost regression (O(n^2), ~5 min at the 1 MiB stdin cap — a DoS on the very hook meant to gate the command) AND still let all three in-scope spellings through (env quote-removal, the `\_` separator, and a leading env option in the value all desync a strings.Fields split and a command-position restart). Branch bugfix/iss-200-env-split-string-guard-bypass-v2 left unpushed. iss-200 enriched with the complete env -S spelling set the next attempt must cover and the design question it now turns on: faithfully modelling env's parser (bounded/quote-aware/option-aware) is more than the "no nested re-tokenizing" the remediation assumed, while the tokenize.go "sh -c unparseable => documented non-match" precedent is a FAIL-OPEN for a denylist guard, so it does not transfer. This is the iss-189/190 pattern — repeated local-patch BLOCKs on one root cause mean the next move is an agreed design, not another patch. Rejected here: hot-patching the reviewers' suggested fixes and re-reviewing in-session (pushing through the STOP on a security-critical guard).

Frontmatter

.abcd/work/decisions/dcn-2608150000000004-iss-200-env-s-guard-bypass-fix-attempt-2.md
open on GitHub ↗ · commit history ↗

mentions2

• iss-189adjacency probe's trailing \b can be satisfied by the window edge instead of real content, causing a spurious over-redaction. scanAllPatterns (scanner.go) slices the line to a bounded window (line[end:min(end+512,len(line))]) before running each pattern's adjacencyProbe, to keep one probe attempt's cost constant regardless of what follows (iss-185's fix). Some probes retain an internal trailing \b of their own (e.g. net_lan_hostname's `\b` at the very end of its alternation) which normally requires a real non-word character (or true end of string) after the match. But when the probe is truncated to the window, "end of window" is treated by the regex engine exactly like "end of string" — so if the window happens to end immediately after what LOOKS like a complete hostname/token, the trailing \b is satisfied by the artificial window boundary rather than by real surrounding content, even though the FULL, untruncated line would not have matched there (the real next byte continues the token). Concrete repro: a line built as `"AKIA"+16*"Q"` (a confirmed match, establishing the probe's junction) + 506 filler bytes + ".local" + "zzz" — the window (512 bytes from the junction) ends exactly after "local", so net_lan_hostname's probe matches "b...local" (satisfied by end-of-window) even though the real line continues with "zzz" right after ".local", meaning the FULL line's own un-windowed net_lan_hostname pattern would NOT match there at all (no real word boundary follows in the actual text). Impact: a spurious net:lan_hostname finding (warn severity only, not hard_fail) causes Redact to needlessly rewrite up to 512 bytes of legitimate content as fingerprinted/starred output — not a security leak (over-redaction, not under-redaction) but a correctness/usability defect: legitimate file content gets mangled on a contrived but reachable input shape. Suggested fix (from the reviewer that found this): when a probe match's end lands exactly at the window's limit AND limit < len(line) (i.e. the window was actually truncated, not naturally at the line's end), re-run that one probe against the full, untruncated line[end:] before accepting the match — paying the larger cost only in this rare edge case rather than on every probe. Found during a merge-gate correctness review of iss-185's PR (bugfix/iss-185-scanner-adjacent-secret-boundary-bypass); non-blocking (contrived input, warn-severity-only impact), so not fixed inline — captured for its own verify-and-fix cycle.
• iss-200guard's env wrapper table listed -S/--split-string as a value-owning flag for the SEPARATE-TOKEN spelling only ('env -S git push --force origin main'), but GNU env -S/--split-string also accepts the value glued to the flag ('env -Sgit push --force origin main', 'env --split-string=git push --force origin main'), which re-splits identically and executes identically; a fix attempted in bug-hunt loop round 9 (bugfix/env-split-string-guard-bypass) closed only the separate-token form and was BLOCKed at pre-PR review by both an independent correctness reviewer and an independent security reviewer, who each independently reproduced that the glued forms remain a complete, silent bypass of every guard blocker on the live PreToolUse path; suggested remediation (from both reviewers, converging independently): in commandOf/skipWrapperArgs, treat -S/--split-string as a value-owning env flag in all three spellings — the exact separate-token form (-S as its own token, value in the following token), the glued form (-S<value>, len>2), and the --split-string=<value> form (value non-empty) — and in every case read the first word of <value> as command position, rather than either treating the whole glued token as a consumed wrapper flag or skipping the following token outright in the separate-token case — no nested re-tokenizing required, contained to the same two functions