What happened
Followed the skill's documented Codex invocation verbatim and the run silently did nothing.
codex exec --skip-git-repo-check -C "<workdir>" --sandbox workspace-write -a never \
-o "<scratchpad>/codex-result-rebase.md" "<prompt>" < /dev/null
Output:
error: unexpected argument '-a' found
tip: to pass '-a' as a value, use '-- -a'
Usage: codex exec [OPTIONS] [PROMPT]
Why it is worth fixing rather than just a stale flag
The arg-parse failure exits 0. Combined with run_in_background, the harness reported "completed (exit code 0)" and the -o file was never created. Nothing in the success path distinguished this from a real run. The skill's own Hard Rule 3 ("read results from output, never from exit codes") is what caught it, so the skill is self-consistent, but the example it tells you to copy is what triggers the trap.
Environment
codex-cli 0.147.0- Windows 11, Git Bash via the Bash tool (as the skill instructs)
What 0.147.0 actually offers
codex exec --help has no -a / --ask-for-approval. The approval-adjacent flags are:
--approve-for-me — route approval requests through automatic review using the workspace-write sandbox--dangerously-bypass-approvals-and-sandbox--dangerously-bypass-hook-trust
Sandbox is -s, --sandbox <read-only|workspace-write|danger-full-access>. codex exec is non-interactive and does not prompt, so no approval flag is needed at all — dropping -a never works and is what I ended up using.
Affected lines
SKILL.md:38 — quick-question exampleSKILL.md:46 — long/write-capable examplereferences/codex-exec.md:20 — flag table row for --ask-for-approval, -areferences/codex-exec.md:49 — "Under -a never, a sandbox-blocked action fails back to the model as a tool-call error"
Suggested fix
Drop -a never from both SKILL.md examples. In references/codex-exec.md, either mark the -a row as removed as of some version or replace it with the current approval flags, and reword line 49 to describe the default headless behavior instead of a flag that no longer parses. A one-line note that a bad flag exits 0 would also be worth adding next to Hard Rule 3, since that is the property that makes this particular staleness expensive.
What happened
Followed the skill's documented Codex invocation verbatim and the run silently did nothing.
Output:
Why it is worth fixing rather than just a stale flag
The arg-parse failure exits 0. Combined with
run_in_background, the harness reported "completed (exit code 0)" and the-ofile was never created. Nothing in the success path distinguished this from a real run. The skill's own Hard Rule 3 ("read results from output, never from exit codes") is what caught it, so the skill is self-consistent, but the example it tells you to copy is what triggers the trap.Environment
codex-cli 0.147.0What 0.147.0 actually offers
codex exec --helphas no-a/--ask-for-approval. The approval-adjacent flags are:--approve-for-me— route approval requests through automatic review using the workspace-write sandbox--dangerously-bypass-approvals-and-sandbox--dangerously-bypass-hook-trustSandbox is
-s, --sandbox <read-only|workspace-write|danger-full-access>.codex execis non-interactive and does not prompt, so no approval flag is needed at all — dropping-a neverworks and is what I ended up using.Affected lines
SKILL.md:38— quick-question exampleSKILL.md:46— long/write-capable examplereferences/codex-exec.md:20— flag table row for--ask-for-approval, -areferences/codex-exec.md:49— "Under-a never, a sandbox-blocked action fails back to the model as a tool-call error"Suggested fix
Drop
-a neverfrom bothSKILL.mdexamples. Inreferences/codex-exec.md, either mark the-arow as removed as of some version or replace it with the current approval flags, and reword line 49 to describe the default headless behavior instead of a flag that no longer parses. A one-line note that a bad flag exits 0 would also be worth adding next to Hard Rule 3, since that is the property that makes this particular staleness expensive.