Repository navigation
fleet(help): fleet help <domain> <extra> silently ignores every argument after the domain name #5652
Description
fleet(help): fleet help <domain> <extra> silently ignores every argument after the domain name
Summary
The root help built-in takes exactly one argument — a domain name — but never
checks for extras. fleet help queue --bogus-junk (or any trailing token)
prints the queue domain help and exits 0, silently discarding the extra
argument. Every sibling root built-in rejects this shape: version,
capabilities, and --version/-V all route through reject_extra_args
and exit 2 naming the unexpected argument (#5572: "Root built-ins take no
arguments: a trailing argument is a usage error naming it, not silently
discarded output"). The help arm is the one root built-in the #5572 sweep
missed, because its first argument is legitimate.
Evidence
pkgs/fleet/crates/fleet/src/main.rs, run_root:
- Lines 669–672: bare
fleet help(one token) prints the full registry help. - Lines 673–684: the
Some("help")arm resolvesargs.get(1)as a domain and
prints its help —args.get(2..)is never inspected. - Contrast lines ~686–707:
--version/version/capabilitieseach call
reject_extra_args(args)first (which namesargs[1], correct there
because those built-ins take no argument at all).
Verified this run against the real binary on the laptop
(pkgs/fleet/target/debug/fleet, built 2026-11-04 12:09 CST from this tree;
the run_root help arm at HEAD 9af042edd0 is the code quoted above):
$ fleet help queue --bogus-junk
fleet queue — Repo work queue: enqueue, claim, and complete tasks through the queue broker.
... (full domain help) ...
EXIT:0
$ fleet help queue # control: identical output
EXIT:0
$ fleet version --bogus-junk # sibling control (#5572 behavior)
error: unexpected argument '--bogus-junk' for 'fleet version'
EXIT:2
Why it matters
This is the same silent-discard bug class the fleet CLI has been closing leaf
by leaf (#5572, #5575, #5592, #5603, #5607): a user who mistypes
fleet help queue claim — plausibly asking for help on the claim
subcommand — gets the domain help with a success exit and no signal that the
second word was dropped, instead of either subcommand help or a usage error.
Scripts and muscle memory both read exit 0 as "that was a valid invocation."
Acceptance criteria
fleet help <domain> <extra>(one or more extras) exits 2 with a usage
error naming the first unexpected argument, consistent with the
reject_extra_argsmessage shape (unexpected argument '<extra>' for 'fleet help').fleet help,fleet help <domain>,fleet --help, and the unknown-domain
error (fleet help nosuchdomain) behave exactly as today.- A pinning test covers the extra-argument rejection alongside the existing
root built-in arity tests incrates/fleet/src/main.rs.
Activity
developing-today commentedon Nov 4, 2026
CODE-1409
dezren39 commentedon Nov 4, 2026
🤖 Agent note · filed
helpbuilt-in inrun_root(pkgs/fleet/crates/fleet/src/main.rs) resolvesargs[1]as a domain and never inspectsargs[2..], sofleet help queue --bogus-junkprints the queue help and exits 0 while sibling built-ins reject extras at exit 2 (fleet: root built-ins (version / capabilities / --version) silently ignore trailing arguments #5572). Verified this run against the real laptop binary (help-with-extra exit 0, identical to the bare-domain control;fleet version --bogus-junkexit 2 naming the argument). Guarded self-solve this run (lifecycle protocol §4): trivial, clearly scoped, no safety labels.fix(fleet): reject arguments after the domain name in fleet help (#5652…
developing-today commentedon Nov 4, 2026
🤖 Agent note · done
run_root's help arm now rejects the first argument after the domain name with the standard usage error (unexpected argument '<extra>' for 'fleet help', exit 2) before printing help; new pinning testroot_help_rejects_arguments_after_the_domain_name.cargo test -p fleet10 passed on the laptop, fmt applied; fixed binary re-probed (extra → exit 2 naming it;help queue→ 0; unknown domain → 2; barehelp→ 0). Work labels stripped; worktree/branch removed.