fix(agent): unentitled Codex primary + fallback no longer oscillate or announce a false restore (#106475, salvage #106482)

[teknium1]

An unentitled Codex primary plus an unentitled Codex fallback now fails closed with one terminal entitlement error instead of alternating "Model fallback" / "Primary model restored" forever with zero delivered answers.

Fixes #106475. Refs #61660, #71970.

Changes

• agent/fallback_cooldown.py::_mark_entitlement_rejected_model — on the non-retryable client-error branch (agent/turn_api_error.py::settle_unrecovered_error), a 400 whose body carries the normalized public text model is not supported when using Codex with a ChatGPT account records the current (provider, model) as dead for the session and emits one user-visible notice pointing at /model. Scoped to single-credential pools only: with ≥2 pool entries another account may be entitled, so the decision is left to credential rotation (Codex credential pool does not rotate on account-specific model entitlement HTTP 400 #71970 / fix(agent): rotate Codex credentials on model entitlement rejection #71973).
• agent/chat_completion_helpers.py::_should_skip_fallback_candidate skips rejected entries (configured or normalized slug form) — the walk exhausts instead of re-selecting a dead slug.
• agent/agent_runtime_helpers.py::restore_primary_runtime returns False when the primary's slug was rejected: the session stays on the current runtime, no unverified "Primary model restored" is announced, and the next turn surfaces the terminal 400 once.
• Marker + predicate live in the topical sibling agent/fallback_cooldown.py (the state shared by the fallback walk and the restore gate) rather than appended to the chat_completion_helpers facade where the original PR put them; the two try/except → False wrappers around pool.entries() / normalize_model_for_provider (never raises) were dropped. Tests trimmed from 8 to the 2 invariants.

Validation

	before (origin/main)	after
Live repro, turn 1	primary 400 → fallback 400 → terminal error	same, plus one 🚫 not entitled notice per slug
Live repro, turn 2 (after the 5 s exhausted-chain cooldown)	✅ Primary model restored … emitted, chain re-walked, both 400s again	no restore notice, no fallback notice, 1 API call, same terminal error
tests/run_agent/test_entitlement_fail_closed.py	2 failed with the marker present but call sites reverted (walk called resolve_provider_client; restore returned True)	2 passed
tests/agent/ + tests/run_agent/	—	8788 passed, 1 failed: test_compression_stall_fallback_78981 — passes alone on this branch and on main, untouched by this diff (isolation flake)

Live repro: in-process harness driving the real run_conversation loop with interruptible_api_call stubbed to return the entitlement 400 for every model, two turns on one agent — before: turn 2 emits Primary model restored and re-walks the chain / after: turn 2 emits nothing but the terminal error. Harness: /tmp/campaign-0909/codex_entitlement_repro.py (one-shot, not committed).

Root cause: restore_primary_runtime switched back to the primary at the start of every turn on the strength of the fallback having also failed, with nothing recording that the account can never use either slug.

Credits

• @liuhao1024 — fix and tests (PR fix(agent): fail closed when Codex account-model entitlement 400s exhaust the chain #106482, cherry-picked with authorship preserved)
• @shivasymbl — report and measurement ([Bug]: unentitled primary + unentitled fallback oscillate forever on openai-codex; "Primary model restored" is emitted without any recovery #106475)
• @kilhyeonjun — multi-credential rotation half of the same 400 (Codex credential pool does not rotate on account-specific model entitlement HTTP 400 #71970 / fix(agent): rotate Codex credentials on model entitlement rejection #71973), deliberately left to that PR

Infographic

[github-actions]

૮ >ﻌ< ა ci review

_{ran on f61a085 — refactor(agent): move the entitlement rejection marker into}

⚠️ Warnings

OSV vulnerability scan · View job

71 known vulnerabilities found in pinned dependencies.

• CVE-2026-83608 in package-lock.json
• CVE-2026-83608 in package-lock.json
• CVE-2026-84375 in package-lock.json
• CVE-2026-84375 in website/package-lock.json
• CVE-2026-67213 in website/package-lock.json
• CVE-2026-85062 in package-lock.json
• CVE-2026-85062 in website/package-lock.json
• CVE-2026-83609 in package-lock.json
• CVE-2026-82417 in scripts/whatsapp-bridge/package-lock.json
• CVE-2026-82417 in website/package-lock.json
• CVE-2026-84369 in website/package-lock.json
• CVE-2026-83605 in package-lock.json
• CVE-2026-83605 in package-lock.json
• CVE-2026-75931 in package-lock.json
• CVE-2026-75931 in website/package-lock.json
• CVE-2026-83610 in package-lock.json
• CVE-2026-83610 in package-lock.json
• CVE-2026-83611 in package-lock.json
• CVE-2026-83611 in package-lock.json
• CVE-2026-71554 in uv.lock

How to fix:

Review the findings in the Security tab. Update the affected dependencies if a patched version is available.

---

debug info

CI timings

CI timings · View report · View job

Wall time 4m53s vs 4m37s (+5.8%). 10 job(s) slower, 3 faster, 1 unchanged.

• Check contributors / check-attribution: -22.0s
• OS-specific tests / Windows-only tests: +17.0s
• Python lints / Windows footguns (blocking): +11.0s
• OSV scan / Scan lockfiles / osv-scan: +10.0s
• OS-specific tests / macOS-only tests: +7.0s