What happens
Every Codex invocation fails immediately on codex-cli 0.154.0. --full-auto has
been removed from the CLI, and the plugin passes it unconditionally:
ask-codex: exit_code=2 duration=0s
error: unexpected argument '--full-auto'
Two call sites, both hard-coded:
scripts/ask-codex.sh:280 CODEX_AUTO_FLAG="--full-auto"
hooks/loop-codex-stop-hook.sh:1211 CODEX_AUTO_FLAG="--full-auto"
So this is not limited to /humanize:ask-codex — the same line sits in the RLCR
loop's stop hook, which is the plugin's main path.
The replacement
--full-auto's successor is --approve-for-me, with the same meaning. From
codex exec --help on 0.154.0:
--approve-for-me
Route approval requests through automatic review using the
workspace-write sandbox
--full-auto appears nowhere in codex exec --help or codex --help on this
version.
Suggested fix
Probe rather than swap — hard-coding --approve-for-me would break older CLIs
exactly the way --full-auto breaks new ones. scripts/ask-codex.sh already
uses this shape a few lines earlier for --disable feature names, where the
comment reads "Codex has used different names across releases, and older CLIs
reject unknown feature names". The same reasoning applies here:
CODEX_AUTO_FLAG=""
_codex_exec_help="$(codex exec --help 2>&1 || true)"
if printf '%s' "$_codex_exec_help" | grep -q -- '--approve-for-me'; then
CODEX_AUTO_FLAG="--approve-for-me"
elif printf '%s' "$_codex_exec_help" | grep -q -- '--full-auto'; then
CODEX_AUTO_FLAG="--full-auto"
fi
if [[ "${HUMANIZE_CODEX_BYPASS_SANDBOX:-}" == "true" ]] || [[ "${HUMANIZE_CODEX_BYPASS_SANDBOX:-}" == "1" ]]; then
CODEX_AUTO_FLAG="--dangerously-bypass-approvals-and-sandbox"
fi
# Empty when the CLI has neither: pass no flag rather than one it will reject.
if [[ -n "$CODEX_AUTO_FLAG" ]]; then
CODEX_EXEC_ARGS+=("$CODEX_AUTO_FLAG")
fi
CODEX_EXEC_ARGS+=("-C" "$PROJECT_ROOT")HUMANIZE_CODEX_BYPASS_SANDBOX keeps overriding to
--dangerously-bypass-approvals-and-sandbox, which is unaffected — that flag
still exists on 0.154.0.
Also referring to the old flag
Not blocking, but they will read as wrong once the fix lands:
docs/usage.md:479 "uses `--full-auto` with sandbox protection"
tests/test-ask-codex.sh:647 help-text fixture
tests/test-bitlesson-select-routing.sh:491 asserts on the literal '--full-auto'
That last one is a test that would need to follow whichever flag the probe picks,
or it will fail on a machine with a current CLI.
Verified
Patched both call sites locally with the above and ran the skill end to end:
ask-codex: exit_code=0 duration=5s
PONG
Before the patch the same invocation gave exit_code=2 duration=0s. The probe
selects --approve-for-me on this machine. I have only exercised
scripts/ask-codex.sh directly; the stop-hook change is the identical edit but
I have not watched it fire in a live loop.
Environment
humanize 1.17.0 (checkout at 517dcf4)
codex-cli 0.154.0
OS NixOS
What happens
Every Codex invocation fails immediately on codex-cli 0.154.0.
--full-autohasbeen removed from the CLI, and the plugin passes it unconditionally:
Two call sites, both hard-coded:
So this is not limited to
/humanize:ask-codex— the same line sits in the RLCRloop's stop hook, which is the plugin's main path.
The replacement
--full-auto's successor is--approve-for-me, with the same meaning. Fromcodex exec --helpon 0.154.0:--full-autoappears nowhere incodex exec --helporcodex --helpon thisversion.
Suggested fix
Probe rather than swap — hard-coding
--approve-for-mewould break older CLIsexactly the way
--full-autobreaks new ones.scripts/ask-codex.shalreadyuses this shape a few lines earlier for
--disablefeature names, where thecomment reads "Codex has used different names across releases, and older CLIs
reject unknown feature names". The same reasoning applies here:
HUMANIZE_CODEX_BYPASS_SANDBOXkeeps overriding to--dangerously-bypass-approvals-and-sandbox, which is unaffected — that flagstill exists on 0.154.0.
Also referring to the old flag
Not blocking, but they will read as wrong once the fix lands:
That last one is a test that would need to follow whichever flag the probe picks,
or it will fail on a machine with a current CLI.
Verified
Patched both call sites locally with the above and ran the skill end to end:
Before the patch the same invocation gave
exit_code=2 duration=0s. The probeselects
--approve-for-meon this machine. I have only exercisedscripts/ask-codex.shdirectly; the stop-hook change is the identical edit butI have not watched it fire in a live loop.
Environment