source-control:babysit-prs: the merge wrapper's --allow-unpinned-head refusal is bypassable by argparse prefix abbreviation

[kyle-sexton]

Problem

bin/source-control-babysit-merge exists to add exactly one refusal on top of babysit_merge.py. Its own header states the purpose:

It additionally refuses --allow-unpinned-head so that no unattended, allow-rule-covered invocation can merge an unvetted head; the interactive unpinned override remains available by invoking babysit_merge.py directly.

That refusal is bypassable by dropping one character from the flag.

Root cause — two halves that disagree

The wrapper filters by exact string equality (bin/source-control-babysit-merge:15-22 on origin/main):

for arg in "$@"; do
  if [[ "$arg" == "--allow-unpinned-head" ]]; then
    printf '%s\n' \
      'source-control-babysit-merge: --allow-unpinned-head is not permitted through the wrapper.' \
      'Invoke babysit_merge.py directly for interactive unpinned use.' >&2
    exit 2
  fi
done

The CLI it wraps builds its parser with argparse's prefix abbreviation left at the default (skills/babysit-prs/scripts/babysit_merge.py:806):

parser = argparse.ArgumentParser(description=__doc__)   # allow_abbrev defaults to True

So any unambiguous prefix — --allow-unpinned-hea, --allow-unpinned-h, --allow-unp — is a valid spelling of the flag to the CLI and an unrecognized string to the wrapper.

Reproduction (on origin/main; both files are byte-identical to main on every open branch checked)

Exact spelling — the guard fires:

$ bash bin/source-control-babysit-merge --allow-unpinned-head
source-control-babysit-merge: --allow-unpinned-head is not permitted through the wrapper.
Invoke babysit_merge.py directly for interactive unpinned use.
RC=2

Abbreviated — the guard does not fire, and argparse accepts the flag rather than reporting an unrecognized argument. Execution proceeds all the way to the owner-allowlist scope check:

$ bash bin/source-control-babysit-merge melodic-software/claude-code-plugins#1285 --allow-unpinned-hea
{"pr": "melodic-software/claude-code-plugins#1285", "inScope": false, "error": "--allowed-owners is required and must be non-empty; refusing to act without an owner allowlist"}
RC=3

RC=3 from the scope check, not RC=2 from the wrapper, is the proof: the argument was consumed as a recognized option. Had argparse rejected it, the failure would have been unrecognized arguments.

Impact

babysit_merge.py:1051 is what the override unlocks:

if not args.expected_head and not args.allow_unpinned_head:

With --merge and a valid --allowed-owners, an invocation that reads as the guarded wrapper form can therefore merge a pull request with no pinned head — the precise outcome the wrapper's existence is justified by. Any consumer whose permission rule is anchored on the wrapper's bare name (which is what the wrapper is packaged for) grants that invocation.

Severity is bounded, not zero, and the bound is a consumer's configuration rather than this repository's code:

• A consumer whose allow rule covers the wrapper only without --merge is not straight-through exploitable, because the merging invocation is judged on its own terms. That is how melodic-software/dotfiles' autoMode.allow is currently written.
• A consumer who grants the wrapper broadly — on the documented reasoning that the wrapper cannot merge an unvetted head — is exposed.

Either way the shipped claim is false, and the defense-in-depth layer the wrapper is named for does not hold.

Suggested fix

Both halves, because either alone leaves a gap:

1. babysit_merge.py:806 — argparse.ArgumentParser(description=__doc__, allow_abbrev=False). This is the root cause and it closes the class, not just this flag: every other option on this parser is equally abbreviatable today, and a future wrapper-side filter would inherit the same hole. Check the other eight lane parsers for the same default before assuming this one is special.
2. bin/source-control-babysit-merge:15-22 — match the flag as a prefix and its --flag=value form rather than by string equality, so the wrapper refuses independently of what the CLI happens to accept. A guard that is correct only because the thing it guards is configured a particular way is not a guard.

Then bind it: the guard contract in #1265 / #1285 publishes merge.unpinned-head-refused-by-wrapper as a proven claim, and no assertion in the suite currently exercises an abbreviated spelling. A row asserting that every prefix of the flag is refused is what keeps this closed.

Provenance

Found by the Codex reviewer on #1285 (guard_contract.py:301, 2026-07-25T07:14:47Z) and independently confirmed empirically here against origin/main before filing. Not introduced by #1285 — that PR only publishes a contract row claiming the refusal holds.

Related

• Guard semantics the lane's consumers restate in prose have no drift detection #1265 — the guard-semantics drift-detection issue; --allow-unpinned-head's bash-vs-Python split is one of the four fact families it names.
• feat(source-control): bind babysit guard semantics to an executable contract #1285 — the contract suite that asserts the refusal without covering abbreviated spellings.

[kyle-sexton]

This was generated by AI during triage.

Triage

Verified — reproduced empirically, not just read from the diff.

Confirmed both halves of the root cause against origin/main:

1. plugins/source-control/bin/source-control-babysit-merge (lines 15-22) filters --allow-unpinned-head by exact string equality only.
2. plugins/source-control/skills/babysit-prs/scripts/babysit_merge.py:806 constructs argparse.ArgumentParser(description=__doc__) with allow_abbrev left at its default (True).

Reproduced the bypass directly against argparse, independent of the report's own repro:

$ python3 -c "
import argparse
p = argparse.ArgumentParser()
p.add_argument('--allow-unpinned-head', action='store_true')
p.add_argument('--merge', action='store_true')
print(p.parse_args(['--allow-unpinned-hea', '--merge']))
"
Namespace(allow_unpinned_head=True, merge=True)

--allow-unpinned-hea (or any unambiguous prefix) sets allow_unpinned_head=True while the wrapper's exact-match loop never fires. This is a real, confirmed bypass of a documented safety refusal — the wrapper's own header claims it "refuses --allow-unpinned-head so that no unattended, allow-rule-covered invocation can merge an unvetted head," and that claim is false for any abbreviated spelling.

Severity: bounded by consumer configuration (per the report's own analysis — a consumer that grants the wrapper broadly, trusting it can't merge an unvetted head, is exposed; a consumer whose allow rule excludes --merge on the wrapper is not straight-through exploitable), but the defense-in-depth guarantee the wrapper is named for does not hold as documented. Rated priority: high, not critical, on that bound.

Classification: Bug, priority: high, area: security, work-class: scoped (a briefed, bounded fix — not a mechanical dependency-bump-style change, since it touches two files plus a contract-test gap and needs the other eight lane parsers checked for the same allow_abbrev default).

Routing: delegable — no open decision. The report's suggested fix is concrete and correct: allow_abbrev=False on the argparse parser (closes the class, not just this one flag) plus a prefix/--flag=value-aware match in the wrapper so the guard doesn't depend on what the CLI happens to accept. Routing autonomous-eligible.

Agent Brief

Type: Bug
Summary: The source-control-babysit-merge wrapper's refusal of --allow-unpinned-head is bypassable because it matches by exact string equality while the Python CLI it wraps accepts any unambiguous prefix of that flag (argparse's default abbreviation behavior).

Current behavior: The wrapper script scans "$@" for the literal string --allow-unpinned-head and exits with a refusal if found. The wrapped CLI's argument parser accepts prefix abbreviations of long options by default, so a shortened spelling (e.g. dropping the last character) reaches the CLI as a valid, recognized flag while the wrapper's literal-match loop never sees it. An unattended, allow-rule-covered invocation can therefore merge a PR with no pinned head — exactly the outcome the wrapper exists to prevent.

Desired behavior: The wrapper's refusal fires for any spelling the underlying CLI would itself accept as --allow-unpinned-head, including abbreviated prefixes and a --flag=value form. Independently, the underlying CLI's argument parser should reject abbreviated spellings entirely, so the guarantee doesn't depend on the wrapper's filter staying in lockstep with whatever the parser happens to accept.

Key interfaces:

• The CLI's top-level argument-parser construction — disable prefix abbreviation.
• The wrapper's pre-flight arg-scanning loop — match the flag and its accepted spellings/forms, not literal equality.
• Any sibling CLI entry points in this skill's scripts directory that build their own argument parsers — check whether they share the same abbreviation exposure before assuming this one parser is the only instance.
• The existing guard-contract test suite that asserts the refusal holds — extend its coverage to assert an abbreviated spelling is refused too, not just the exact flag.

Acceptance criteria:

• Invoking the wrapper with any unambiguous prefix of --allow-unpinned-head (or a --flag=value form of it) is refused the same way the exact spelling is refused.
• The underlying CLI itself rejects abbreviated long-option spellings as unrecognized arguments (verified by attempting an abbreviated invocation directly against the CLI, bypassing the wrapper).
• Every other argument parser constructed by this skill's CLI scripts is checked for the same default-abbreviation exposure and fixed if present.
• The guard-contract test suite gains a case asserting an abbreviated spelling of the unpinned-head flag is refused.

Out of scope:

• Changing the interactive (non-wrapper) unpinned-head override path — it remains available by invoking the underlying CLI directly, unchanged.
• Any change to owner-allowlist or scope-check behavior downstream of the flag check.

[kyle-sexton]

[kyle-sexton]

Claimed and executed autonomously by the /work-items:work-loop worker lane (frontier tier; security-surface work class → frontier capability tier). The interactive selection confirmation was satisfied by the invoker's own admission decision: the item was named explicitly, its admission gate had already passed (agent-ready, no needs-human, priority: high, area: security, work-class: scoped), and no branch/PR/assignee touched it at dispatch. Claim held via the tracker seam (assignee + lease, lease_comment_id above).

PR: #1382 — branch fix/1371-babysit-merge-wrapper-abbrev-bypass.

Both halves of the suggested fix are implemented, plus the check the issue asked for on the other lane parsers:

• The wrapper now refuses any ---prefixed argument that is a prefix of --allow-unpinned-head (and its --flag=value form), so it holds independently of the CLI's parser configuration.
• All nine babysit-prs lane parsers now pass allow_abbrev=False — not just babysit_merge.py. The issue's "check the other eight before assuming this one is special" turned up the same default on every one of them, and the class this closes is wider than the reported flag: --mer was an accepted spelling of --merge on origin/main, so a consumer allow rule that grants the wrapper but not with --merge — the configuration the issue names as bounding the severity — was bypassable by the same mechanism.

Regression coverage was written red first against unmodified origin/main (8 Python failures, 9 bash rows failing) and asserts the wrapper's refusal text rather than exit 2, which is overloaded three ways on this path. --allow-unp is exactly that trap: it exits 2 on unfixed main via argparse ambiguity, so a code-only assertion would have been green before and after. An AST scan additionally holds the whole scripts/ directory to allow_abbrev=False so a new lane script cannot reopen the class.

Deliberately out of scope, for #1285: the guard-contract row. guard_contract.py exists only on feat/1265-guard-contract-suite, not on main, so the row asserting that every prefix of the flag is refused belongs to that branch. Noted in the PR's ## Related as well.

---

This was generated by AI during work-loop execution.