Codex engine model setting is not honored when compiled as -c model=...

[chrizbo]

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-mini

This was compiled with:

gh aw compile --no-check-update
gh aw validate --no-check-update

Both 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

[pelikhan]

@chrizbo try the prereleases

[chrizbo]

Tried v0.74.2 prerelease as suggested. That does appear to address the compile-time side of this issue.

Using the v0.74.2 binary directly:

/private/tmp/gh-aw-v0.74.2 compile --no-check-update
/private/tmp/gh-aw-v0.74.2 validate --no-check-update

Both passed for the repo workflows. The regenerated lock files now invoke Codex with --model instead of -c model=...:

codex ${GH_AW_MODEL_AGENT_CODEX:+--model "$GH_AW_MODEL_AGENT_CODEX" }exec ...

Example generated env still has the intended provider-scoped model:

GH_AW_MODEL_AGENT_CODEX: openai/gpt-5-mini
GH_AW_MODEL_DETECTION_CODEX: openai/gpt-5-mini

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 of gpt-5.5.

[chrizbo]

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:

• harness spawn: codex --model openai/gpt-5-mini exec ...
• session configured: model: "openai/gpt-5-mini", model_provider_id: "openai-proxy"
• summary: Model: openai/gpt-5-mini

New issue: the agent still fails before doing useful work with:

Missing environment variable: OPENAI_API_KEY.

The generated lock validates OPENAI_API_KEY successfully 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 awf command excludes both from the sandboxed execution:

--exclude-env CODEX_API_KEY ... --exclude-env OPENAI_API_KEY

The 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_KEY to 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 an env_key that Codex validates inside the sandbox?