[App] API-key custom providers skip remote model refresh, hiding GPT-5.6 from the picker

What version of the Codex App are you using (From “About Codex” dialog)?

Latest public Codex App releases available on 2026-07-10, independently reproduced on Windows and macOS. Both affected users confirmed that no App update was available. I do not have their exact About-dialog build numbers; the related CLI diagnostics below were captured with codex-cli 0.144.1.

What subscription do you have?

API-key authentication against an OpenAI-compatible custom provider. The same affected users also have ChatGPT accounts, and GPT-5.6 appears normally in the App picker when they use the official ChatGPT provider.

What platform is your computer?

Independently reproduced in Codex App on Windows and macOS. The CLI diagnostics were captured on Fedora Linux x86_64.

What issue are you seeing?

Codex App does not show GPT-5.6 models in the model picker when an API-key-authenticated custom provider is selected, even though all of the following are true:

• The provider's Responses API can successfully run gpt-5.6-sol when the model is configured explicitly.
• GET {base_url}/models?client_version=0.144.1 returns HTTP 200 with a valid Codex models manifest containing gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna as visible/listed models.
• The same App installations show the GPT-5.6 family when using official ChatGPT authentication.
• Codex CLI 0.144.1 can use gpt-5.6-sol with the same custom provider and API key.

With the custom provider selected, affected App users only see models through GPT-5.5. This makes inference availability and picker availability disagree: the model works when named explicitly, but cannot be discovered or selected in the App UI.

This appears to involve two client-side catalog boundaries: the core model refresh gate for API-key custom providers, and possibly the Desktop renderer's additional model filtering.

What steps can reproduce the bug?

1. Sign in to Codex with API-key auth.
2. Configure a Responses-compatible custom provider:

```toml
model = "gpt-5.6-sol"
model_provider = "gateway"

[model_providers.gateway]
name = "Gateway"
base_url = "https://gateway.example.com/v1"
wire_api = "responses"
requires_openai_auth = true
```

1. Have the provider return a valid Codex manifest from GET /v1/models?client_version=<version>, including visible entries such as:

``json
{
"models": [
{ "slug": "gpt-5.6-sol", "visibility": "list" },
{ "slug": "gpt-5.6-terra", "visibility": "list" },
{ "slug": "gpt-5.6-luna", "visibility": "list" }
]
}
``

(Other required ModelInfo fields are omitted here for brevity; the tested endpoint returns the complete upstream manifest.)

1. Fully restart Codex App and open the model picker.
2. Observe that the GPT-5.6 entries are absent under the custom provider.
3. Set model = "gpt-5.6-sol" directly, or invoke the same provider from Codex CLI, and observe that the model request succeeds.
4. Switch the App back to official ChatGPT authentication and observe that the GPT-5.6 entries appear in the picker.

No credentials, account IDs, or private gateway URLs are required for the reproduction.

What is the expected behavior?

For an authenticated custom provider, Codex should refresh the provider-owned /models endpoint and expose visible models from the effective catalog in the App picker.

At minimum:

• API-key auth should not prevent an otherwise authenticated custom provider from refreshing its remote model catalog.
• The Desktop picker should not remove provider-returned visible models solely because they are absent from a first-party ChatGPT rollout/allowlist.
• A model that is usable and configured as the current model should be shown by its real slug instead of being absent or reduced to Custom.

Additional information

Direct endpoint verification

The tested gateway returned HTTP 200 from both supported route shapes, with all three GPT-5.6 slugs:

/v1/models?client_version=0.144.1
/backend-api/codex/models?client_version=0.144.1

gpt-5.6-luna
gpt-5.6-sol
gpt-5.6-terra

CLI catalog diagnostic

On codex-cli 0.144.1 with an API-key custom provider:

codex debug models           -> 8 models, including all three GPT-5.6 variants
codex debug models --bundled -> 8 models, including all three GPT-5.6 variants
effective catalog == bundled catalog

This explains why the CLI can appear healthy even when the provider catalog is not refreshed: GPT-5.6 is already present in the 0.144.1 bundled catalog.

Current source path

On current main (4ba28150146e8ae8e949a07951639a929f5ddeae), refresh_available_models returns before fetching unless should_refresh_models() succeeds:

• manager.rs lines 335-392
• models_endpoint.rs lines 68-72
• auth.rs lines 45-54

The refresh predicate is currently:

self.endpoint_client.uses_codex_backend().await
    || self.endpoint_client.has_command_auth()

A normal API-key custom provider satisfies neither branch, even when it has valid auth and a working /models endpoint. This is consistent with the earlier API-key catalog report in #15843.

There may also be a second Desktop-only filter after app-server model/list, as described in #19694. The generic custom-provider picker gap is tracked in #10867. This report is narrower: current API-key custom providers with a valid remote Codex manifest cannot make newly available models such as GPT-5.6 appear in the App picker, while explicit model use succeeds.

The documented custom-provider configuration is here: https://developers.openai.com/codex/config-advanced/#custom-model-providers

Suggested regression coverage:

1. Configure a custom provider with API-key auth and a mock /models response.
2. Assert that an online refresh reaches that endpoint and updates app-server model/list.
3. Assert that a visible provider model is retained by the Desktop picker.