A backslash inside a token walked past the blocker

Four dangerous commands were allowed while bash still executed the dangerous form. Pick one to see the measured verdict before and after PR #3289, and which of the two defects let it through. Nothing here is inferred; every value came from running the live hook.

Pick a command

Before #3289
allow
After #3289
deny
What bash actually ran
rm -rf /

The two defects

1. The normalizer separated tokens that bash joins. normalize-command.ts replaced a backslash-newline with a space. Bash joins the tokens on either side, so rm -r⏎f / normalized to rm -r f /, matching no dangerous pattern, while bash ran rm -rf /. It now joins to the empty string. The regex also tightened from \\\s*[\r\n]+ to \\\r?\n, because bash only treats a backslash immediately followed by a newline as a continuation.

2. The interpreter-pipe scanner reads raw text. pipesToShellInterpreter deliberately reads the word after a pipe off the raw string to track quote state (the #2955 follow-up). With |⏎bash the target began with a backslash and matched no interpreter. The call site now joins continuations before the scan, closing the evasion without disturbing the quote scanning that fix exists to protect.

Why the existing tests missed it. dangerous-command-blocker.test.ts:261 does cover line-continuation bypass and passes. But every case there splits between tokens, where substituting a space is harmless. No test ever split a token in half. The suite measured the easy half of the case and reported the whole thing green.

PR #3289· 7539 hook unit tests· 17/17 security suite· false positives re-checked, all still allow