Summary
The skill's Codex invocations all specify -a never. That flag does not exist in codex-cli 0.147.0. Every documented command shape fails immediately, and because codex exec prints a bare usage message and exits 0, the failure looks like a successful run that produced no output.
Expected vs actual
Expected (per SKILL.md, "Driving Codex"):
codex exec --skip-git-repo-check -a never "<prompt>" < /dev/null
Actual on 0.147.0:
Usage: codex exec [OPTIONS] [PROMPT]
codex exec [OPTIONS] <COMMAND> [ARGS]
For more information, try '--help'.
Exit code: 0. The -o/--output-last-message file is never created.
This is a nasty combination: an agent following the skill, driving Codex in the background and trusting the harness's completion signal, sees "exit code 0" and an empty result file. Hard rule 3 in the skill ("read results from output, never from exit codes") is what caught it — but the skill's own example is what triggered it.
Cause
codex exec --help on 0.147.0 has no -a / --ask-for-approval. Approval handling was reworked into:
--approve-for-me — route approval requests through automatic review using the workspace-write sandbox--dangerously-bypass-approvals-and-sandbox- otherwise, config (
-c) / profile
Sandbox is still -s, --sandbox <read-only|workspace-write|danger-full-access>, and -o, --output-last-message <FILE> is still correct.
What worked
codex exec --skip-git-repo-check -C "<workdir>" -s read-only \
-o "<scratchpad>/codex-result.md" "<prompt>" < /dev/null
With -s read-only no approvals are requested, so nothing is needed in place of -a never.
Suggested fix
- Drop
-a never from the command shapes in SKILL.md, or replace it with a version check and the 0.147.0-appropriate flag.
- Add a note to
references/codex-exec.md that approval flags changed, with the current set.
- Consider adding a hard rule: a bare
Usage: block on stdout means the flags were rejected, regardless of exit code — worth calling out explicitly since it presents identically to "ran fine, said nothing."
Environment
- codex-cli 0.147.0
- Windows 11, Git Bash via the Bash tool
- Invoked with
run_in_background, subscription auth (no API key env vars set)
Summary
The skill's Codex invocations all specify
-a never. That flag does not exist in codex-cli 0.147.0. Every documented command shape fails immediately, and becausecodex execprints a bare usage message and exits 0, the failure looks like a successful run that produced no output.Expected vs actual
Expected (per
SKILL.md, "Driving Codex"):Actual on 0.147.0:
Exit code: 0. The
-o/--output-last-messagefile is never created.This is a nasty combination: an agent following the skill, driving Codex in the background and trusting the harness's completion signal, sees "exit code 0" and an empty result file. Hard rule 3 in the skill ("read results from output, never from exit codes") is what caught it — but the skill's own example is what triggered it.
Cause
codex exec --helpon 0.147.0 has no-a/--ask-for-approval. Approval handling was reworked into:--approve-for-me— route approval requests through automatic review using the workspace-write sandbox--dangerously-bypass-approvals-and-sandbox-c) / profileSandbox is still
-s, --sandbox <read-only|workspace-write|danger-full-access>, and-o, --output-last-message <FILE>is still correct.What worked
With
-s read-onlyno approvals are requested, so nothing is needed in place of-a never.Suggested fix
-a neverfrom the command shapes inSKILL.md, or replace it with a version check and the 0.147.0-appropriate flag.references/codex-exec.mdthat approval flags changed, with the current set.Usage:block on stdout means the flags were rejected, regardless of exit code — worth calling out explicitly since it presents identically to "ran fine, said nothing."Environment
run_in_background, subscription auth (no API key env vars set)