`codex exec --help` references `-a on-request` but `codex exec --ask-for-approval` is rejected

Resolved 💬 1 comment Opened Mar 5, 2026 by kankosanin-gif Closed Apr 6, 2026

What version of Codex CLI is running?

codex-cli 0.106.0

What subscription do you have?

Plus

Which model were you using?

_No response_

What platform is your computer?

_No response_

What terminal emulator and version are you using (if applicable)?

_No response_

What issue are you seeing?

The codex exec --help text suggests approval behavior via --full-auto alias (-a on-request, --sandbox workspace-write), but codex exec does not accept --ask-for-approval directly.

Repro command:

codex exec --sandbox read-only --ask-for-approval never "test"

Actual output:

error: unexpected argument '--ask-for-approval' found

This creates confusion because top-level codex --help advertises --ask-for-approval, while exec help references -a semantics indirectly.

What steps can reproduce the bug?

  1. Run codex --help and note that --ask-for-approval is listed.
  2. Run codex exec --help and note --full-auto description references -a on-request behavior.
  3. Execute:

``bash
codex exec --sandbox read-only --ask-for-approval never "test"
``

  1. Observe the parser error: unexpected argument '--ask-for-approval' found.

This appears to be a UX/docs inconsistency between top-level and exec subcommand options.

What is the expected behavior?

Expected one of the following:

  • codex exec should accept --ask-for-approval if approval policy is intended to be configurable in exec mode, or
  • codex exec --help should avoid referencing -a on-request semantics and clearly document what approval options are actually supported for exec.

Additional information

This is likely a CLI UX/documentation mismatch. Happy to open a docs PR if maintainers prefer clarifying help text first.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗