Repository navigation
Codex engine model setting is not honored when compiled as -c model=... #32413
Description
Summary
When an Agentic Workflow uses the Codex engine with an explicit model, gh-aw preserves the configured model in metadata and generated environment variables, but the Codex runtime still initializes and calls the Responses API with the default gpt-5.5 model.
This causes the GitHub Actions UI / gh-aw metadata to show the requested model while actual OpenAI usage is billed against gpt-5.5.
Workflow configuration
Source workflow frontmatter:
engine:
id: codex
model: openai/gpt-5-miniThis was compiled with:
gh aw compile --no-check-update
gh aw validate --no-check-updateBoth compile and validate succeeded.
Generated lock / action behavior
The compiled lock file contains the expected model metadata and environment values, for example:
agent_model: openai/gpt-5-mini
GH_AW_INFO_MODEL: openai/gpt-5-mini
GH_AW_MODEL_AGENT_CODEX: openai/gpt-5-mini
GH_AW_MODEL_DETECTION_CODEX: openai/gpt-5-mini
GH_AW_ENGINE_MODEL: openai/gpt-5-mini
The generated action then invokes Codex like this:
codex -c model=openai/gpt-5-mini exec -c web_search=disabled -c fetch=disabled ...
Actual runtime behavior
In the completed Actions run, Codex still initialized with gpt-5.5 and sent gpt-5.5 to the Responses API.
Run: https://github.com/chrizbo/agentics-beyond-code/actions/runs/25925869595
Relevant log lines from the agent phase:
GH_AW_MODEL_AGENT_CODEX: openai/gpt-5-mini
[codex-harness] ... spawning: codex -c model=openai/gpt-5-mini exec ...
SessionConfiguredEvent ... model: "gpt-5.5", model_provider_id: "openai-proxy"
model_client.stream_responses_api{model=gpt-5.5 ...}
The detection phase showed the same pattern:
GH_AW_MODEL_DETECTION_CODEX: openai/gpt-5-mini
[codex-harness] ... spawning: codex -c model=openai/gpt-5-mini exec ...
SessionConfiguredEvent ... model: "gpt-5.5", model_provider_id: "openai-proxy"
model_client.stream_responses_api{model=gpt-5.5 ...}
POST ... /responses: {"model":"gpt-5.5", ...}
Expected behavior
When engine.model is set to openai/gpt-5-mini, the Codex runtime should use openai/gpt-5-mini or the resolved mini model, and the actual Responses API request should not fall back to gpt-5.5.
Impact
This makes cost controls unreliable. The workflow metadata and Actions UI imply the lower-cost model is being used, but OpenAI usage is actually billed at gpt-5.5 rates.
Possible fix
This looks like the generated Codex invocation may be using a config form that Codex 0.128.0 does not honor for model selection:
codex -c model=... exec ...
Codex CLI appears to expose a model flag (-m / --model). The gh-aw Codex engine template or harness may need to invoke Codex with the model flag form that Codex actually treats as a provided model, for example:
codex exec -m openai/gpt-5-mini ...
or the equivalent supported placement for the Codex CLI version used by gh-aw.
Versions / context
- gh-aw compiler version in lock metadata:
v0.72.1 - Codex version reported in generated run info:
0.128.0 - Workflow branch:
openai-aw-updates - Repository run used for evidence: https://github.com/chrizbo/agentics-beyond-code/actions/runs/25925869595
Activity
pelikhan commentedon May 15, 2026
@chrizbo try the prereleases
chrizbo commentedon May 15, 2026
Tried
v0.74.2prerelease as suggested. That does appear to address the compile-time side of this issue.Using the
v0.74.2binary directly:Both passed for the repo workflows. The regenerated lock files now invoke Codex with
--modelinstead of-c model=...:Example generated env still has the intended provider-scoped model:
I pushed the prerelease-generated locks to my PR branch and will rerun the same workflow to confirm the runtime
SessionConfiguredEvent/ Responses API request now uses the requested mini model instead ofgpt-5.5.chrizbo commentedon May 15, 2026
Tried the v0.74.2 prerelease and it does fix the model flag generation in my repo: compiled lock files now invoke Codex with
--model "$GH_AW_MODEL_AGENT_CODEX"instead of-c model=....I pushed that compile output here: chrizbo/agentics-beyond-code@701a1fb
I then reran Daily Standup Prep on the branch: https://github.com/chrizbo/agentics-beyond-code/actions/runs/25929907528
The good news: the runtime now shows the requested model reaching Codex:
codex --model openai/gpt-5-mini exec ...model: "openai/gpt-5-mini", model_provider_id: "openai-proxy"Model: openai/gpt-5-miniNew issue: the agent still fails before doing useful work with:
Missing environment variable: OPENAI_API_KEY.The generated lock validates
OPENAI_API_KEYsuccessfully in activation and sets both:CODEX_API_KEY: ${{ secrets.CODEX_API_KEY || secrets.OPENAI_API_KEY }}OPENAI_API_KEY: ${{ secrets.CODEX_API_KEY || secrets.OPENAI_API_KEY }}But the
awfcommand excludes both from the sandboxed execution:--exclude-env CODEX_API_KEY ... --exclude-env OPENAI_API_KEYThe generated Codex config also sets:
model_provider = "openai-proxy"env_key = "OPENAI_API_KEY"So my read is: v0.74.2 fixes the original model-selection bug, but Codex still expects
OPENAI_API_KEYto exist in its process environment even when using the gh-aw OpenAI proxy, while the firewall intentionally excludes that secret from the agent container. Should gh-aw inject a non-secret placeholder env var for the proxy provider, use a different auth path for Codex when the AWF proxy is active, or avoid setting anenv_keythat Codex validates inside the sandbox?