exec: -i/--image before [PROMPT] silently drops the prompt

Description

codex exec -i <FILE> <PROMPT> silently drops the prompt when -i/--image appears before the positional [PROMPT] argument. Instead of using the supplied prompt, Codex falls back to reading a prompt from stdin — and since stdin is typically empty/non-interactive in this scenario, it then fails with No prompt provided via stdin.

This reproduces with a real, existing image file (not a missing-file issue), and is not fixed by an explicit -- separator, which should normally force everything after it to be treated as positional.

Steps to reproduce

# Fails: prompt is silently discarded
codex exec -i path\to\image.png "describe this" --skip-git-repo-check

# Also fails, even with an explicit end-of-options separator:
codex exec -i path\to\image.png -- "describe this" --skip-git-repo-check

# Works correctly: reordering so the prompt comes first
codex exec "describe this" -i path\to\image.png --skip-git-repo-check

Expected behavior

The prompt "describe this" should be used regardless of where -i appears on the command line — or, failing that, Codex should give a clear parse error rather than silently discarding the prompt and falling through to an unrelated "no prompt via stdin" failure.

Actual behavior

• With -i <FILE> before the prompt: Codex prints Reading prompt from stdin..., then exits with No prompt provided via stdin. The prompt text supplied on the command line is never used.
• With -i <FILE> after the prompt: works correctly (proceeds to start a real session, printed the OpenAI Codex v0.149.1 banner and config normally).

Root cause hint

-i, --image <FILE>... is defined as accepting multiple values (per codex exec --help, the arity is <FILE>...). This is consistent with a clap argument-parsing ambiguity where a preceding variadic/multi-value option continues greedily consuming subsequent positional-looking tokens meant for [PROMPT], rather than yielding once no more -i-prefixed values are being supplied.

That an explicit -- separator does not fix the ordering (-i image.png -- "describe this" still fails) suggests this may go beyond simple greedy consumption of the next positional-looking token, and is worth a closer look at how the image and prompt arguments interact in the exec subcommand's clap definition.

Environment

• codex-cli version: 0.149.1
• Install method: npm (npm install -g @openai/codex)
• OS: Windows 11 Pro (10.0.26100), x86_64
• This is CLI argument-parsing behavior rather than filesystem/OS-specific, so it likely reproduces on macOS/Linux as well (untested there).

Minor related note

While investigating this area, codex apply --help and codex login --help both show a blank/missing description line for <TASK_ID> and --device-auth respectively — small doc-completeness gaps, mentioning here in case it's a quick fix alongside this.

Start by locating the Rust clap definition for the exec subcommand, especially the image and positional prompt arguments. Reproduce the ordering and -- cases from the issue, then add regression coverage showing that the prompt is retained or that an explicit parse error is reported instead of reading stdin.