Problem
When the engine: codex workflow uses a model override (e.g. gpt-5.1-codex-mini), the model flag is silently ignored and codex falls back to its default (gpt-5.3-codex). The root cause is a shell-expansion ordering issue in the command string executed inside the AWF agent container.
The generated command looks like:
codex \$\{GH_AW_MODEL_AGENT_CODEX:+-c model="$GH_AW_MODEL_AGENT_CODEX" }exec \
-c web_search="disabled" --dangerously-bypass-approvals-and-sandbox \
--skip-git-repo-check "$INSTRUCTION"
Here exec is the subcommand but it appears after the -c model=… flag. Codex interprets -c model=… as a top-level global flag before it has seen the exec subcommand; the value is discarded. The corrected form is:
codex exec \
\$\{GH_AW_MODEL_AGENT_CODEX:+-c model="$GH_AW_MODEL_AGENT_CODEX" } \
-c web_search="disabled" --dangerously-bypass-approvals-and-sandbox \
--skip-git-repo-check "$INSTRUCTION"
AWF's containers/agent/entrypoint.sh logs this at startup ([entrypoint] Executing command: …) and executes it verbatim — it passes the command string through unchanged. The bug therefore manifests inside the AWF container but originates in the command template emitted by the gh-aw compiler for the codex engine.
Context
Original report: github/gh-aw#25304
Observed in a live run: https://github.com/drehelis/gcp-emulator-ui/actions/runs/24133256297/job/70414880919#step:21:104
Root Cause
The gh-aw compiler constructs the codex invocation string (likely in a codex engine template). The \$\{GH_AW_MODEL_AGENT_CODEX:+…} expansion must be placed after the exec subcommand, not before it. AWF's entrypoint.sh (containers/agent/entrypoint.sh:401) executes the string as-is, so the fix must be in the compiler template, not in AWF.
Proposed Solution
-
Compiler fix — in the codex engine template, move exec before any -c model=… flag:
codex exec \$\{GH_AW_MODEL_AGENT_CODEX:+-c model="$GH_AW_MODEL_AGENT_CODEX" }-c web_search="disabled" \
--dangerously-bypass-approvals-and-sandbox --skip-git-repo-check "$INSTRUCTION"
-
AWF validation (optional hardening) — entrypoint.sh could detect and warn when the codex invocation appears malformed (e.g. first positional arg to codex is -c rather than exec), to surface similar issues earlier in logs.
Generated by Firewall Issue Dispatcher · ● 720.5K · ◷
Problem
When the
engine: codexworkflow uses a model override (e.g.gpt-5.1-codex-mini), the model flag is silently ignored and codex falls back to its default (gpt-5.3-codex). The root cause is a shell-expansion ordering issue in the command string executed inside the AWF agent container.The generated command looks like:
Here
execis the subcommand but it appears after the-c model=…flag. Codex interprets-c model=…as a top-level global flag before it has seen theexecsubcommand; the value is discarded. The corrected form is:AWF's
containers/agent/entrypoint.shlogs this at startup ([entrypoint] Executing command: …) and executes it verbatim — it passes the command string through unchanged. The bug therefore manifests inside the AWF container but originates in the command template emitted by the gh-aw compiler for the codex engine.Context
Original report: github/gh-aw#25304
Observed in a live run: https://github.com/drehelis/gcp-emulator-ui/actions/runs/24133256297/job/70414880919#step:21:104
Root Cause
The gh-aw compiler constructs the codex invocation string (likely in a codex engine template). The
\$\{GH_AW_MODEL_AGENT_CODEX:+…}expansion must be placed after theexecsubcommand, not before it. AWF'sentrypoint.sh(containers/agent/entrypoint.sh:401) executes the string as-is, so the fix must be in the compiler template, not in AWF.Proposed Solution
Compiler fix — in the codex engine template, move
execbefore any-c model=…flag:AWF validation (optional hardening) —
entrypoint.shcould detect and warn when the codex invocation appears malformed (e.g. first positional arg tocodexis-crather thanexec), to surface similar issues earlier in logs.