You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[aw-failures] Daily Sub-Agent Model Resolution Audit 100% red — Codex gpt-5-codex-alpha-2025-11-07 404s (same alpha-snapshot d
[Content truncated due to length] #42033
Apply the #41787 fix repo-wide — stop pinning the Codex alpha snapshot gpt-5-codex-alpha-2025-11-07. The same 404 defect tracked for Daily Cache Strategy Analyzer in #41787 also breaks this workflow, here 100% red for 5+ days.
Scope expansion of #41787 (not a duplicate).#41787 documents the alpha-snapshot 404 for a single workflow (Cache Strategy Analyzer, ~50% red). This issue records a second confirmed affected workflow with the identical signature and a worse cadence (every scheduled run since 6-24). Filing separately because the affected workflow and severity differ; fix should be cross-workflow.
Problem statement
The Execute Codex CLI step fails: every /responses sampling call returns 404 Not Found: Model not found gpt-5-codex-alpha-2025-11-07. The Codex harness retries 5× in-CLI, then classifies isInvalidModelError=true and does not retry the process (invalid/unsupported model configuration — not retrying). turns=0, 0 tokens, agent does zero useful work, job exits 1.
[codex-harness] awf-reflect: fetched 213 model(s) from (apiproxy/redacted)
[codex-harness] attempt 1: spawning: codex exec --model gpt-5.4-mini ...
{"type":"error","message":"unexpected status 404 Not Found: Model not found gpt-5-codex-alpha-2025-11-07, url: (172.30.0.30/redacted) ..."}
{"type":"turn.failed","error":{"message":"... Model not found gpt-5-codex-alpha-2025-11-07 ..."}}
[codex-harness] attempt 1 failed: ... isInvalidModelError=true ...
[codex-harness] attempt 1: invalid/unsupported model configuration — not retrying
Key detail: the harness top-level --model gpt-5.4-mini resolves fine (it is among the 213 models the proxy advertises). The 404 is on the actual /responses sampling call, which targets the pinned alpha snapshot gpt-5-codex-alpha-2025-11-07. So a sub-agent / Codex internal model config still pins the alpha snapshot even though the top-level agent model was migrated off it — directly relevant given this workflow audits sub-agent model resolution.
Affected workflow and run IDs
Workflow: Daily Sub-Agent Model Resolution Audit (.github/workflows/daily-model-resolution.lock.yml), engine codex.
Firewall is clean (15/15 requests allowed, 0 blocked) — this is purely model availability, not network/firewall.
Probable root cause
Identical to #41787: a preview/alpha Codex snapshot (gpt-5-codex-alpha-2025-11-07) that the AIC api-proxy (172.30.0.30:10000) does not serve. Here the snapshot is pinned for a sub-agent / Codex sampling config rather than the top-level agent model, so migrating the agent model alone did not fix it. There is no degraded mode — every sampling call 404s and the run is a total loss.
Make the Codex harness fail fast on 404 model not found (already non-retried, but it still burns 5 in-CLI sampling retries first) and surface the offending model name in the job summary.
Add a compile-time / preflight check that rejects known-unavailable alpha snapshots in workflow + sub-agent frontmatter so this cannot reach CI.
Success criteria / verification
A subsequent scheduled Daily Sub-Agent Model Resolution Audit run reaches turns>0 and completes without a 404.
No Codex-engine workflow or sub-agent config references gpt-5-codex-alpha-2025-11-07.
Apply the #41787 fix repo-wide — stop pinning the Codex alpha snapshot
gpt-5-codex-alpha-2025-11-07. The same 404 defect tracked forDaily Cache Strategy Analyzerin #41787 also breaks this workflow, here 100% red for 5+ days.Scope expansion of #41787 (not a duplicate). #41787 documents the alpha-snapshot 404 for a single workflow (Cache Strategy Analyzer, ~50% red). This issue records a second confirmed affected workflow with the identical signature and a worse cadence (every scheduled run since 6-24). Filing separately because the affected workflow and severity differ; fix should be cross-workflow.
Problem statement
The
Execute Codex CLIstep fails: every/responsessampling call returns404 Not Found: Model not found gpt-5-codex-alpha-2025-11-07. The Codex harness retries 5× in-CLI, then classifiesisInvalidModelError=trueand does not retry the process (invalid/unsupported model configuration — not retrying).turns=0, 0 tokens, agent does zero useful work, job exits 1.Key detail: the harness top-level
--model gpt-5.4-miniresolves fine (it is among the 213 models the proxy advertises). The 404 is on the actual/responsessampling call, which targets the pinned alpha snapshotgpt-5-codex-alpha-2025-11-07. So a sub-agent / Codex internal model config still pins the alpha snapshot even though the top-level agent model was migrated off it — directly relevant given this workflow audits sub-agent model resolution.Affected workflow and run IDs
.github/workflows/daily-model-resolution.lock.yml), enginecodex.Execute Codex CLI, 404 model-not-found,turns=0.Probable root cause
Identical to #41787: a preview/alpha Codex snapshot (
gpt-5-codex-alpha-2025-11-07) that the AIC api-proxy (172.30.0.30:10000) does not serve. Here the snapshot is pinned for a sub-agent / Codex sampling config rather than the top-level agent model, so migrating the agent model alone did not fix it. There is no degraded mode — every sampling call 404s and the run is a total loss.Proposed remediation
gpt-5-codex-alpha-2025-11-07; repoint to a stable/GA Codex model (or add a fallback). This generalizes [aw-failures] Daily Cache Strategy Analyzer ~50% red — Codex pinned to alpha snapshot gpt-5-codex-alpha-2025-11-07 that 404s on [Content truncated due to length] #41787 beyond Cache Strategy Analyzer.404 model not found(already non-retried, but it still burns 5 in-CLI sampling retries first) and surface the offending model name in the job summary.Success criteria / verification
turns>0and completes without a 404.gpt-5-codex-alpha-2025-11-07.