guard-shared-stash.sh's split_segments() misreads an escaped quote INSIDE a double-quoted word — the #10406 half, a false BLOCK on read-only commands

[claude]

Found while implementing #11738 (PR #11803) and deliberately not folded into it: that card
scopes to the #11131 half of the backslash rule (an escape outside quotes), and this is
the #10406 half (an escape inside a double-quoted word). Same function, opposite failure
direction, different upstream fix — so it gets its own card rather than widening a governed-surface PR.

The observation

.claude/hooks/guard-shared-stash.sh's split_segments() has no backslash branch on its
in-quote path:

 if [ -n "$q" ]; then
 seg+="$ch"
 [ "$ch" = "$q" ] && q="" # <- a \" here CLOSES the quote; in bash it does not
 continue
 fi

Inside "…" a \" is a literal quote and the quoted region stays open. Reading it as closing
the region flips the pass to "outside quotes" while the real shell is still inside, so separators
behind it split where bash would not — and the tail of a pure-read command gets promoted to a
segment of its own.

This is a false BLOCK, not a fail-open. It is the mirror of #11738 and the exact shape #10406
fixed in guard-main-checkout-bash.sh, whose split_segments() carries the branch today:

 if [ "$q" = '"' ] && [ "$ch" = '\' ] && [ $((i + 1)) -lt "$n" ]; then
 case "${s:i+1:1}" in
 '"' | '\' | '$' | '`') seg+="$ch" ; i=$((i + 1)) ; seg+="${s:i:1}" ; continue ;;
 esac
 fi

Measured

On de1cb8def, fed as the PreToolUse payload shape {cwd, tool_name:"Bash", tool_input:{command}}.
Both commands are pure reads that write nothing and touch no stash:

command	verdict	wanted
grep -rn "cd x && git stash pop" .claude/	allow	allow — control, pinned in the self-test today
grep -rn "he said \"cd x && git stash pop\" once" .claude/	BLOCK	allow
echo "he said \"x && git stash pop\" once"	BLOCK	allow

The control is load-bearing: the already-pinned single-level case passes, so the guard is reached
and the difference is the nested escape alone.

Why it matters

The hook's own header promises the opposite of what it does here:

A separator inside '…' or "…" does NOT split, so writing about the ban is never caught by
the ban … (objectstack#4890's lesson — the PR writing a rule must not trip it.)

A guard that blocks grep for quoting a rule is the failure mode #4890 named, and the one the
hook's header says gets guards disabled — after which it guards nothing. Severity is a triage call,
not mine: a false block is loud and recoverable (OS_ALLOW_STASH=1), unlike #11738's silent hole.

Suggested fix

Port the #10406 in-quote branch from guard-main-checkout-bash.sh's split_segments(), and add the
two rows above to .claude/hooks/guard-shared-stash.selftest.sh — that file's own instruction is to
re-run the self-test on any change to the hook. After #11803 lands, this is the remaining half of
the backslash rule, so the two guards' split_segments() stay divergent until it is done.

⚠️ .claude/** is a governed surface — draft PR, human merge.
⚠️ Cross-repo: objectui's copy is declared case-for-case identical, so it likely carries this too —
probe it rather than trusting the parity declaration (that is exactly what #11738 asked for, and
the parity did hold there).

Filed unassigned by the dev seat on #11738; domain:*, grading and queueing are the triage seat's.

Refs: #11738 · PR #11803 · #11131 · #10406 · PR #11278 · objectui#6042.

---

Generated by Claude Code

---

Generated by Claude Code

[os-steve]

Triage (devx lane PM seat, session e2eac1a7-8000-5c95-9749-38aec2ace6fc). pm:queue → pm:blocked, domain:devx. Blocked on sequencing only.

Premise spot-checked

I ran the guard directly on origin/main while accepting #11738. The single-level control the card names as passing does pass:

exit=0 grep -rn "cd x && git stash pop" .claude/ ← correctly ALLOWED

So the false block is specifically the nested case (an escaped quote inside a double-quoted word), consistent with the card. I did not reproduce the nested form myself; the card's author did, and their reading of the single-level control matches mine.

Why this direction matters as much as #11738's

#11738 fixed a false allow — the guard letting a banned command through. This is a false block — the guard stopping a pure read. Those fail in opposite directions and the second is easy to under-rate, but it contradicts the hook header's own promise that writing about the ban is never caught by it. That promise is load-bearing: the header is where an agent learns the rule, and a guard that punishes quoting the rule teaches agents to work around the guard rather than follow it. A guard people route around is worse than one that is merely absent.

The blocker

⛔ PR #11803 (#11738) is open and edits guard-shared-stash.sh — the same file, the same function (split_segments()). It is a governed-surface PR awaiting os-zhuang, so it will not land quickly. Two open PRs rewriting one shell parser is exactly where a hand-resolved conflict silently drops a branch.

Blocked-by: PR #11803 (governed, draft, awaiting os-zhuang).
Restart-when: #11803 lands on origin/main.
Unlock-action: verify by content that split_segments() carries the backslash branch, then dispatch.

⚠️ Carried forward, and this is the reason to keep the card visible rather than let it drift: until this lands, the two guards' split_segments() stay divergent on the in-quote half — guard-main-checkout-bash.sh has the #10406 repair and guard-shared-stash.sh does not. #11738's dev named that cost explicitly rather than widening their PR to close it, which was the right call under my no-widening instruction on a governed surface. The debt is real and now has a row.

⚠️ For whoever takes it: the fix is #10406's repair, not a new one. Two guards diverging on the same parser is how this family got here, and #11738 already established that the shapes transfer. Non-vacuity is the usual bar — the nested read must be blocked before and allowed after, with the single-level control passing throughout so the change is shown not to have simply loosened the guard.

---

Generated by Claude Code