Repository navigation
fix(agents): three gh forms the reworked push gate still does not judge #797
Description
Activity
Five more forms from the final review of that branch, all pre-existing in the tokenizer rather than introduced by its last commit. Labels are the reviewer's: measured means run through the gate.
<<inside arithmetic swallows the following lines.n=$(( 1 << 3 ))followed on the next line by a guardedghcommand orgit pushis allowed: the tokenizer registers the<<as a heredoc and the pending delimiter3eats every later line. For theghchecks this is a regression againstmain's regex gate, which blocked it (measured). The push half existed onmainalready (inferred).- The push check doesn't follow a heredoc a shell reads inside
$(…)(out=$(bash <<'EOF'…git push ……EOF)is allowed, measured), while theghchecks now do. The push check reads the body-less form of the substitution. - An unquoted heredoc's body runs
$(…), but neither check follows it (cat <<EOF/$(…)/EOF, measured). The "a mention in a heredoc body doesn't count" rule assumes a quoted delimiter. - A computed
query=is matched against the whole call, so another field's heredoc text naming a mutation trips it. A false positive on an unusual form. - Nested escaped backticks aren't followed (
x=`echo \`…\``), before and after the change.
— Posted by Claude Code on behalf of @EricAndrechek
Two more from the review of the create-time reviewer/assignee block added to the same branch (both measured through the gate by the reviewer):
- A glued short-flag cluster led by another letter passes. On
gh pr create,-fr aliceor-fa alice(fill plus reviewer/assignee, as pflag reads it) is allowed, because the check matches only a token that starts with-ror-a. Covering any single-dash cluster containingr/awould also catch values the loop scans (see 7), so it needs care. - A value starting with
-aor-ron create is refused with the reviewer message, e.g. a-b "-a thing"body, because the loop scans value tokens as well as flags. Rare (markdown bullets are- xwith a space) and loud rather than a bypass; the existing title handling has the same value-scanning shape.
— Posted by Claude Code on behalf of @EricAndrechek
- A glued short-flag cluster led by another letter passes. On
- added a commit that references this issue
on Oct 9, 2026
Problem
The reworked push gate (the
make ci-remotePR that closes #790) judges eachgh pr/gh apicall on its own, including code handed to a shell and code inside$(…). Review of that change found three forms it still does not judge. Each is less common than the forms the PR covers, so they were left for this follow-up rather than another round on that PR. The gate's stated goal is guarding against accidents, not deliberate workarounds.Forms not judged
All three are inferred from reading
.claude/hooks/agent-bash-gate.shon that branch; none was run.-R/--repobetweenprand its subcommand.gh pr -R o/r ready 12,gh pr --repo o/r create …andgh pr --repo=o/r review 12 --approve. The gate reads the first word afterpras the subcommand, here-R. Whetherghaccepts the flag in that position is unverified (it is a persistent flag ongh pr, which suggests it does). The gate already handles-Rbeforepr.${x:-$(…)}. Past the cap, leftover pieces are refused only if they match the gate'sghregex, which expectsghafter start-of-line, whitespace or a separator, so a quoted'gh pr ready'in a leftover piece (for example$(bash -c 'gh pr ready 12')as the 65th piece) is let through unjudged. Separately, a substitution inside a parameter-expansion default,${x:-$(gh pr ready 12)}, is never queued, because its saved text starts with${.-F query=@-or--input -fed by a heredoc on the same line. The body is on the command line, but values starting with@are skipped. The gate's docs already list--inputand-F field=@fileas unseen, so this is a documented limit; the same-line heredoc case is the one the gate could read.Related
#790, #787, #755, #740