Greptile P1 findings (both verified by running GNU sed against the hook):
1. Escaped replacements evade the check: GNU sed decodes \xHH, \oOOO, \dNNN,
case operations and unknown escapes like \g before executing an s///e
replacement or e operand. Scanning the raw text let \x67it decode to git.
Decoding that surface faithfully is out of scope, so any backslash in an
exec-bearing fragment now throws UnsupportedSedEscape and the hook blocks
with an explicit reason — mirroring the existing env -S escape precedent
instead of pretending to interpret sed. Escaped-newline continuations of an
e operand are refused by the same check.
2. Continued commands went unchecked: the e operand reader stopped at every
newline, but GNU sed joins escaped newlines into one operand. Now covered
by the same conservative refusal.
Also decomposes the sed readers into sub-50-line helpers per the repository
function-size rule (AGENTS.md): readSedDelimited, readSedCommand,
readSedExecute, readSedLineOperand, assertSedLiteral.
5 regression tests pin the escape paths and the benign boundary (a backslash
in a non-executing script stays data). Suite: 810/810.
chenhz01
95964ee623