[App] Model picker shows duplicate GPT-5.6-Terra because codex-auto-review is exposed as Terra

[duarbdhks]

Summary

The Codex Desktop model picker shows GPT-5.6-Terra twice.

The current models_cache.json contains two different slugs with identical user-visible metadata:

[
  {
    "slug": "codex-auto-review",
    "display_name": "GPT-5.6-Terra",
    "visibility": "list",
    "priority": 2
  },
  {
    "slug": "gpt-5.6-terra",
    "display_name": "GPT-5.6-Terra",
    "visibility": "list",
    "priority": 2
  }
]

This makes an internal auto-review model appear as a second Terra entry.

Environment

• Platform: macOS
• Desktop cache client_version: 0.146.0
• Local CLI used for comparison: codex-cli 0.144.6
• Cache ETag: W/"ad1812e980593919a4e61fc64e50566b"

Reproduction

1. Start Codex Desktop with its refreshed model catalog.
2. Open the model picker.
3. Observe two adjacent GPT-5.6-Terra entries.
4. Inspect ~/.codex/models_cache.json and observe the two records above.

The cache is actively refreshed with client_version=0.146.0; deleting or manually editing it is not durable.

Comparison with the bundled catalog

codex debug models --bundled and the refreshed catalog from codex-cli 0.144.6 both return the expected identities:

gpt-5.6-terra    GPT-5.6-Terra    list    priority=2
codex-auto-review Codex Auto Review hide  priority=43

So this does not appear to originate from user config.toml or a duplicate custom provider. It appears specific to the catalog/cache path used by the Desktop 0.146.0 runtime or its server-side cohort.

Expected behavior

• gpt-5.6-terra is the only visible GPT-5.6-Terra entry.
• codex-auto-review remains callable for internal review flows but is returned as Codex Auto Review, visibility=hide, priority=43.

Suggested fix

Restore the codex-auto-review catalog metadata without changing its slug, routing, capabilities, or entitlement:

display_name = Codex Auto Review
visibility   = hide
priority     = 43

As a defensive UI measure, the picker could also report visible display-name collisions and show the slug when a collision occurs.

Related issue

#33146 also concerns model-cache/catalog divergence, but it reports missing GPT-5.6 models from a stale older cache. This report is different: the current 0.146.0 cache exposes codex-auto-review as a duplicate visible Terra entry.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex Desktop model picker shows two indistinguishable GPT-5.6 Luna entries #35305

Powered by Codex Action

[glasses666]

I can confirm this is not only a duplicate-label/UI problem: it can route a normal user task to the internal reviewer and produce a hard 400.

Environment

• macOS arm64
• Codex Desktop embedded runtime: 0.146.0-alpha.3.1
• model cache client_version: 0.146.0
• UI selection: GPT-5.6-Terra, highest reasoning
• user config: model = "gpt-5.6-terra", model_reasoning_effort = "max"

Runtime evidence

The failed turn's persisted turn_context contained:

{
  "model": "codex-auto-review",
  "effort": "max"
}

The request then failed with:

Invalid value: 'max'. Supported values are: 'none', 'minimal', 'low', 'medium', 'high', and 'xhigh'.
param: reasoning.effort
status: 400

So the picker displayed Terra, but the actual request used codex-auto-review. This is especially confusing because the real gpt-5.6-terra accepts max and ultra, while the reviewer accepts only through xhigh.

Cache refresh race / recurrence

The same ~/.codex/models_cache.json was observed changing between these two states during one running Desktop session:

correct:   codex-auto-review  Codex Auto Review  hide  priority=43  low..xhigh
incorrect: codex-auto-review  GPT-5.6-Terra      list  priority=2   low..ultra

After a correct refresh, it was overwritten with the incorrect Terra metadata again roughly 30 seconds later. Therefore deleting or manually editing the cache is not a durable workaround.

As a diagnostic workaround, I restored the correct hidden reviewer metadata and temporarily made the cache immutable. After that, all of these clean ephemeral probes succeeded end-to-end:

gpt-5.6-terra + max
gpt-5.6-terra + ultra
gpt-5.6-luna  + max

A previously failing Desktop thread also resumed successfully when explicitly overridden to gpt-5.6-terra + max; its new turn_context recorded the correct slug.

This suggests the catalog/cache refresh path is intermittently replacing the entire codex-auto-review metadata record with Terra's public metadata, not merely duplicating a display string in the UI.

[rmilkowski]

I see the same issue

[rmilkowski]

Confirmed on macOS with Codex Desktop 26.721.41059 (build 5848) and embedded codex-cli 0.146.0-alpha.3.1.

My global config uses model = "gpt-5.6-sol" and approvals_reviewer = "guardian_subagent". There is no project .codex/config.toml, custom model provider, or model_catalog_json override.

A fresh cache from 2026-07-27T09:09:40Z, with client_version = 0.146.0 and ETag W/"ad1812e980593919a4e61fc64e50566b", contains:

codex-auto-review  GPT-5.6-Terra  list  priority=2
gpt-5.6-terra      GPT-5.6-Terra  list  priority=2

Meanwhile, codex debug models --bundled correctly reports:

codex-auto-review  Codex Auto Review  hide  priority=43
gpt-5.6-terra      GPT-5.6-Terra       list  priority=2

Therefore, the duplicate remains reproducible on build 5848 and appears to come from the refreshed catalogue rather than a custom model configuration.

Screenshot attached.

[surlymochan]

Additional reproduction on a newer macOS Desktop build, with an A/B check that rules out the configured HTTP-only provider as the cause.

Environment

• macOS 26.5.1, Apple Silicon
• ChatGPT/Codex Desktop 26.727.51351 (build 6119)
• Embedded CLI 0.146.0-alpha.9.2
• Model cache client_version: 0.146.0

Reproduction and catalog evidence

The Desktop picker showed two adjacent rows labeled 5.6 Terra. During the same running Desktop session, the shared model cache alternated between these states:

correct:
gpt-5.6-terra     GPT-5.6-Terra     list  priority=2
codex-auto-review Codex Auto Review hide  priority=43

incorrect:
gpt-5.6-terra     GPT-5.6-Terra     list  priority=2
codex-auto-review GPT-5.6-Terra     list  priority=2

The incorrect reviewer record also inherited Terra's reasoning levels through max and ultra. Multiple distinct ETags were observed while the local configuration remained unchanged. A later refresh restored the hidden reviewer metadata, confirming that deleting or editing the cache is not a durable fix.

The bundled catalog is consistently correct:

gpt-5.6-terra     GPT-5.6-Terra     list  priority=2  low..ultra
codex-auto-review Codex Auto Review hide  priority=43 low..xhigh

Provider/WebSocket A/B

I compared the raw catalog returned with:

1. the built-in model_provider = "openai"; and
2. a custom OpenAI-authenticated provider using the same ChatGPT Codex backend with wire_api = "responses" and supports_websockets = false.

Both produced the same duplicate visible records when the bad catalog cohort was active. This isolates the symptom from HTTP/SSE vs Responses WebSocket transport and from the custom provider ID.

Current safe workaround

Explicitly setting model = "gpt-5.6-terra" avoids accidentally selecting codex-auto-review, but it does not remove the duplicate picker row. A static model_catalog_json with the reviewer retained as visibility: "hide" removes the row, but pins the catalog and prevents automatic model updates.

This newer-build reproduction supports both fixes already proposed here:

1. restore the server-side codex-auto-review metadata; and
2. defensively keep internal reviewer slugs out of user-facing pickers even if a remote catalog mistakenly marks them visible.

The cache oscillation also appears consistent with the originator-scoping problem in #33593.