›_ Codex Issues
Codex Issues / #37379

Codex Desktop hides custom models in API-key-only sessions

Open 💬 4 comments Opened Aug 7, 2026 by jadelaglace
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex?

  • Codex Desktop: 26.730.8199.0 (Windows MSIX)
  • Codex CLI: 0.146.1
  • OS: Windows 11 x64

What issue are you seeing?

When Codex Desktop is configured with a custom/OpenAI-compatible provider and API-key-only authentication, the app-server resolves the custom model catalog correctly, but the Desktop model picker is either omitted or shows only custom.

The affected setup has no official ChatGPT/OpenAI account session in the Desktop app. auth.json contains an API key, and the custom provider is configured with requires_openai_auth = true.

The custom models in this setup include:

  • qwen3.7-plus
  • qwen3.7-max
  • deepseek-v4-flash-0731

Steps to reproduce

  1. Configure a custom provider and model_catalog_json in config.toml.
  2. Authenticate with the provider API key only; do not sign in with an official ChatGPT/OpenAI account.
  3. Verify that the CLI and app-server return the custom models from model/list.
  4. Open the Codex Desktop model picker.
  5. Observe that the model selector is not rendered, or that the models are filtered out and the current model is displayed as custom.

Setting the model directly still works:

model = "deepseek-v4-flash-0731"

Expected behavior

Models returned by the app-server from an explicitly configured local catalog should appear in the Desktop model picker, even when the session uses a custom provider and API-key-only authentication. The picker should use the catalog display_name/slug rather than a fabricated provider + reasoning-effort label.

Additional information

This appears to be a Desktop frontend filtering/rendering issue rather than a provider or cache problem:

  • Rewriting models_cache.json, changing its version, and refreshing its timestamp do not resolve the picker behavior.
  • The app-server continues to return the custom models correctly.
  • As a temporary Windows workaround, adding 127.0.0.1 ab.chatgpt.com to hosts, fully exiting Desktop, and deleting the WebView Local Storage\\leveldb directory causes the custom models to appear in the picker. This strongly suggests that a remotely supplied filtering policy is hiding them.

The workaround has the known side effect that online features such as Approve for me may stop working.

Related issues:

  • #10867 - Support custom model providers in app
  • #19694 - Desktop model picker filters models returned from model_catalog_json
  • #34487 - Desktop model_catalog_json models not shown in picker
  • #36582 - Custom-provider model shown as Custom High / incorrect model identity

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 21 days ago

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

  • #36582

Powered by Codex Action

17738302 · 20 days ago

Reproduced on my setup as well.

Environment:

  • Codex Desktop: 26.803.41515 (Windows MSIX)
  • OS: Windows 11 x64
  • Auth: API key only (no ChatGPT sign-in)
  • Custom provider via local proxy: base_url = "http://127.0.0.1:15721/v1", wire_api = "responses", requires_openai_auth = true
  • model_catalog_json points to a local catalog file with one model (kimi/kimi-k3, visibility = "list")

Behavior:

  • The catalog file is valid; the provider's /v1/models endpoint returns the custom model correctly.
  • Sessions run fine with the custom model when it's set directly via model = "kimi/kimi-k3" in config.toml.
  • The Desktop model picker (bottom-right) shows the custom section as empty, so the model cannot be selected from the UI.

The backend resolves the catalog correctly; the picker UI appears to filter the custom models out, exactly as described in this issue.

rnett · 16 days ago

Additional data point (Windows, Codex Desktop). This exact case reproduces even though auth is already API-key-only — we switched to ApiKey and the picker still collapses the custom models into a single "Custom" row.

Versions

  • codex-cli 0.147.0 (standalone install)
  • Desktop MSIX OpenAI.Codex_26.803.10989.0_x64 (internal 26.803.81509)

Auth is ApiKey-only (no ChatGPT/OpenID token anywhere), yet the picker still shows "Custom"

  • codex login status → Logged in using an API key - sk-place***-noop (auth mode ApiKey)
  • ~/.codex/auth.json contains only the keys auth_mode and OPENAI_API_KEY (no ChatGPT/OpenID token field)
  • codex doctor → model provider requires OpenAI auth false, auth storage mode File

The CLI lists all 14 custom models; the app shows one "Custom"

  • codex debug models returns all 14 custom slugs (deepseek-v4-flash, neuralwatt/deepseek-v4-flash, hetzner/deepseek-v4-flash, glm-5.2, meta/muse-spark-1.2-contributor, kimi-k3, etc.), all visibility=list.
  • ~/.codex/config.toml: model = "neuralwatt/deepseek-v4-flash", model_provider = "litellm" (no provider_default, no [profiles]).
  • ~/.codex/models_cache.json does not exist.

So this is a pure custom-only ApiKey setup (no ChatGPT token) and the app still shows a single "Custom" row instead of the custom models that the CLI resolves fine. Happy to provide redacted config details if useful (no secrets).

claell · 5 days ago

Related to API-key-first setups: provider configurations that use env_key instead of experimental_bearer_token naturally end up in API-key-only sessions, so this hiding behavior directly affects the setups third-party tooling tends to recommend.

Cross-referencing #29156 for the broader Desktop custom-provider picker discussion.