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

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

• #35305

Powered by Codex Action

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.

I see the same issue

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.

<img width="1081" height="321" alt="Image" src="https://github.com/user-attachments/assets/a8b8346c-7b21-4d6f-af2e-4bb4edda42b6" />

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.