Repository navigation
fix(rig-acp): rig acp refuses an option after acp instead of ignoring it - #3142
Merged
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
fix(rig-acp): rig acp refuses an option after acp instead of ignoring it
Description
From the 2026-11-07 architecture audit (K3-A, f-1).
Invocation::parseputs every word after a command into itsarguments. rig-acp reads only the options beforeacp(Invoked::flag(TOOLS)) and never reads the arguments. Sorig acp --tools=readstarted an ACP server whose sessions ran with every tool, not only the ones the user asked for, and nothing said so.The router now refuses at startup when any word follows
acp. It says why on stderr and exits with code 2, through the usualrefuse_runpath. An editor that launchesrig acp --tools=readsees:Why in rig-acp, not the shared parser.
rig acptakes no words, so refusing any word there leaves every other command's parsing as it is. ChangingInvocation::parseto read options after a command would change all commands, and their words are the command's to read.What users see change
rig acp --tools=read(or any word afteracp) no longer starts an ACP server. It exits with code 2 and prints on stderr that nothing is taken afteracpand options go before it, as inrig --tools=read acp.rig --tools=read acp(options beforeacp) works as before.acpis silently droppedrig-acptests::an_option_after_acp_is_refusedrig acp needs rig's home, …), never for the trailing option. At the head, the trailing option is refused first.Changelog
rig acprefuses any word afteracp, such asrig acp --tools=read, saying to put options beforeacp, instead of ignoring it.Migration
None. A command line that put options after
acpwas already ignoring them. It now has to put them beforeacp.Type of change
Testing
cargo nextest run --locked --profile local -p rig-acpon box2: 37 of 37 passedcargo clippy --locked -p rig-acp --all-targets -- -D warningson box2: cleancargo xtask verify --affected --base origin/mainon box2: "All 10 checks passed"Checklist:
CHANGELOG.mdorMIGRATING.md(they are generated at release)Notes
plugins/rig-acp/src/router.rs). Test lines: +25.f-1.diff): that test asked the shared parser to read the option as a flag or refuse it. This fix refuses in rig-acp, for the reason above.rig acp --helpis now refused the same way. Before, it was ignored and the server started.rig acp --tools=readfrom a real editor. The refusal goes through the samerefuse_runpath (stderr, exit code 2) as rig-acp's other startup refusals.Follow-ups