fix: treat task --help and unknown flags as CLI errors (#539) - #547
fix: treat task --help and unknown flags as CLI errors (#539)#547stantheman0128 wants to merge 1 commit into
Conversation
Reject unrecognized --options instead of swallowing them into the prompt, and print usage for --help/-h without dispatching a Codex thread. Co-authored-by: Cursor <cursoragent@cursor.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0e0cd92549
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (rejectUnknownOptions) { | ||
| throw new Error(`Unknown option: -${shortKey}`); |
There was a problem hiding this comment.
When task is invoked in the documented quoted raw-argument form, normalizeArgv re-splits the natural-language prompt before it reaches this parser, so any prompt that mentions a short CLI flag or negative-style token now fails here before Codex is dispatched. For example, task "investigate grep -R usage" exits with Unknown option: -R instead of sending that prompt, which is a common shape for debugging command-line behavior; the parser should either stop option parsing once prompt text starts or avoid rejecting single-dash tokens for prompt-taking commands.
Useful? React with 👍 / 👎.
…pstream openai#547) `task --help` did not print usage -- it started a real Codex thread with "--help" as the prompt and burned quota. Only the bare subcommand slot handled --help (codex-companion.mjs), so anything after `task` was prompt text. The same hole let an unknown flag be swallowed silently, which is how --resume-last got hijacked (upstream openai#539). Adopted upstream PR openai#547 verbatim: a `help` boolean plus `rejectUnknownOptions` in parseArgs, and a short-circuit at the top of each subcommand handler. Verified empirically: `task --help` now prints usage, exits 0, and `status --all` shows no job was dispatched. Mutation-checked both halves -- removing handleTask's short-circuit or clearing rejectUnknownOptions each fails its test. Windows suite: 95 tests / 83 pass / 12 fail, against a 91 / 79 / 12 baseline. No new failures. Not covered by this PR's tests: the help short-circuit in the other seven handlers. Identical one-liners, left as-is.
1 participant
Summary
parseArgsgainsrejectUnknownOptionsso unrecognized--flagsthrow instead of becoming prompt text.--help/-h, and print usage without starting a Codex thread.AI assistance
Assisted by Cursor/Grok. I reviewed the diff, ran the tests below, and checked open PRs for overlap (#128/#535 are test-only coverage; #378 is adversarial focus parsing).
Evidence
Test plan
task --help --cwd <tmp> --jsonprints Usage and exits 0task --not-a-real-flagerrors withUnknown optionand does not create a threadtaskprompt still runs under fake-codex