Repository navigation
Prevent stale GPT-5.2 fallback in the official Codex model picker after route restore #104
Copy link
Copy link
Open
Labels
bugSomething isn't workingSomething isn't workingneeds-infoWaiting on reporter for more informationWaiting on reporter for more informationwayfinder:researchWayfinder evidence or research ticketWayfinder evidence or research ticket
Description
Problem
After switching CodexHub from the Gateway route back to the official Codex route and cold-starting Codex Desktop, the model picker can show an extra 5.2 entry even though the current official Codex model list for this account does not expose GPT-5.2.
This must remain distinct from the third-party glm-5.2 model.
Current evidence
- The restarted client is using the official
chatgpt.com/backend-api/codexroute and WebSocket Responses transport. - The freshly fetched official model cache for Codex client 0.144.0 exposes seven list-visible models:
gpt-5.6-sol,gpt-5.6-terra,gpt-5.6-luna,gpt-5.5,gpt-5.4,gpt-5.4-mini, andgpt-5.3-codex-spark; it does not containgpt-5.2. - The official visible-Task creation capability advertises the same seven models and does not advertise GPT-5.2.
- Codex's bundled fallback model catalog still contains a list-visible
gpt-5.2entry. - During the route-restore cold start, remote model refresh initially failed with
timeout waiting for child process to exit; a later online refresh wrote the correct official cache.
Working hypothesis
The picker initialized from the bundled fallback catalog while the online refresh was unavailable, then failed to remove the legacy GPT-5.2 item after the official catalog became available. This is not yet a confirmed ownership assignment between Codex Desktop and CodexHub's client-restore lifecycle.
Scope
- Reproduce
Gateway -> official route -> cold startwith both a fresh and an existing model cache. - Correlate the picker contents with bundled fallback, online model cache, and model-manager refresh events.
- Determine whether CodexHub leaves stale client/catalog state or merely exposes an upstream Codex reconciliation defect.
- If CodexHub owns the state, restore the official client without leaving unsupported picker entries.
- If upstream owns it, document a bounded CodexHub recovery/workaround and retain evidence suitable for an upstream report.
Acceptance criteria
- A deterministic reproduction distinguishes the bundled fallback list from the account's online official list.
- After official route restoration and online refresh, the picker matches the current official list and does not retain unsupported GPT-5.2.
- Existing thread history that used GLM-5.2 or historical GPT-5.2 is preserved.
-
gpt-5.2,gpt-5.2-codex, and third-partyglm-5.2remain distinct identities. - Tests or replay evidence cover refresh timeout followed by a successful catalog refresh.
Exclusions
- Do not change OpenAI model availability or entitlements.
- Do not delete thread history or the state database as a workaround.
- Do not alias GPT-5.2 to GLM-5.2.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't workingneeds-infoWaiting on reporter for more informationWaiting on reporter for more informationwayfinder:researchWayfinder evidence or research ticketWayfinder evidence or research ticket
Activity
NOirBRight commentedon Jul 25, 2026
Coordinator triage for the 0.1.7 window (2026-07-25): recommend defer
implementation unless one bounded current-version observation reproduces
CodexHub-owned residue.
Why:
or Codex 0.145.0 replay.
model_catalog_json(src-python/config_overlay.py), and current tests coverthose cleanup boundaries.
native model cache before stopping app-server.
successful online refresh replaces the in-memory fallback catalog. Picker UI
reconciliation after that replacement is upstream-owned unless CodexHub
residue is demonstrated.
state, nor a CodexHub seam that can directly assert Desktop picker contents.
Minimal decision observation:
devwith Codex 0.145, perform Gateway → Restore Official → fullycold-start Desktop.
model/list, and the picker before/after one successful online refresh.route-specific cache transition reproduces GPT-5.2. Otherwise retain it as
an upstream observation and remove it as a release blocker.
No code change or broad test is justified before that observation. Issue
remains
ready-for-human; this comment is a keep/defer recommendation, not aclaim that the acceptance criteria passed.
NOirBRight commentedon Jul 25, 2026
0.1.7 triage disposition — deferred
Decision: defer from 0.1.7 to 0.1.9 / needs-info.
Evidence:
model_catalog_json, and the maintained Official catalog excludes GPT-5.2.This is not a 0.1.7 release blocker without a current-version reproduction. To reactivate, capture one bounded current-dev/Codex-0.145 cold-start observation after Gateway → Restore Official, correlating restored config, native cache,
model/list, and visible picker IDs/timestamps. Promote only if CodexHub residue or a CodexHub-specific transition reproduces GPT-5.2.NOirBRight commentedon Aug 2, 2026
Roadmap disposition
Keep #104 in 0.1.9 with needs-info. Beta1's #303 and Beta2's #273/#274 do not prove this old Direct-Official picker-cache claim, and no current-version CodexHub-owned residue has been reproduced. P1 is removed because 0.1.8 is the active iteration. Reactivate only with the bounded current-version observation already requested in the issue.