Support custom model providers in app

[iwinux]

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

260205.1301 (554)

What subscription do you have?

None

What issue are you seeing?

I'm using custom model provider for Codex CLI and App. In CLI, /model is available and switching models works as expected. However, in Codex App, this happens (notice the absence of model switcher):

What steps can reproduce the bug?

1. set up custom model provider & profile

   profile = "internal"
   
   [features]
   # remote_models = false
   
   [profiles.internal]
   # model = "gpt-5.2"
   model_provider = "internal"
   model_reasoning_effort = "medium"
   
   [model_providers.internal]
   name = "Interal LLM Gateway"
   base_url = "http://llms.example.com/v1"
   wire_api = "responses"

2. launch Codex App

What is the expected behavior?

It should provider the same model switcher as in ChatGPT subscription mode:

Additional information

No response

[harshit97]

Ran into the same thing

I'm using a custom model provider behind an internal gateway and hit exactly this: CLI works great (/model lets me switch), but the Desktop app (v26.217.1959, build 669, as of Feb 19 2026) just... doesn't show the model picker at all.

Spent some time tracing through the Electron bundle to figure out what's going on. For anyone unfamiliar, the Codex Desktop app is an Electron app, and you can extract its bundled source from the asar archive at Codex.app/Contents/Resources/app.asar using npx asar extract.

Root cause: In the frontend JS (index-X7Ur8m0p.js inside the extracted asar), the composer footer component conditionally renders both the model picker and the reasoning effort picker only when requiresAuth is truthy:

const c = o.requiresAuth;
c && f.jsxs(f.Fragment, {children: [
    !S && f.jsx(Lpn, {conversationId: e}),  // model picker
    !M && f.jsx(Fpn, {conversationId: e})    // reasoning effort picker
]})

When you use a custom model provider without a ChatGPT or OpenAI API key login, the frontend sees requiresAuth = false and the entire picker block gets skipped. The backend side is actually fine — models pass filtering correctly and the frontend allowlist (mft) includes models like gpt-5.2-codex and gpt-5.2 for non-ChatGPT auth. It's purely a UI gating issue.

Also worth noting: the source on main as of Feb 21 2026 has a model_catalog_json config key (in codex-rs/config/src/lib.rs) that looks like it was meant to help with this — letting you point to a local model catalog file. But it doesn't exist in the current shipped binary (v26.217.1959, build 669). Setting it in config.toml is silently ignored.

What I think the fix would look like:

The conditional should render the model picker regardless of auth mode when there are models available. Something like showing the picker when requiresAuth || hasCustomProvider — the model filtering logic already handles scoping the list correctly per auth type.

Would love to see this fixed since the Desktop app is otherwise really nice with custom providers.

[adrixgc]

Ran into the same/similar problem

We are using LiteLLM as a proxy to expose custom models via /v1/models. The endpoint correctly returns our custom model IDs, for example:

{
  "data": [
    {
      "id": "desarrollo-v4-gpt-5.3-codex",
      "object": "model",
      "created": 1677610602,
      "owned_by": "openai"
    },
    {
      "id": "desarrollo-v4-gpt-5.2-codex",
      "object": "model",
      "created": 1677610602,
      "owned_by": "openai"
    },
    {
      "id": "desarrollo-v4-gpt-5.1-codex-mini",
      "object": "model",
      "created": 1677610602,
      "owned_by": "openai"
    }
  ],
  "object": "list"
}

Problem:

The issue is not with LiteLLM or the endpoint itself.

The problem is that Codex CLI and Codex Desktop UI do not properly support or expose these custom models:

• Users cannot easily discover available models
• They must manually input exact model IDs in config.toml
• The CLI/UI do not present these models as selectable options

Expected Behavior:

• Codex CLI and Desktop UI should:

  • Fetch models from gateway's /v1/models
  • Display them as selectable options
  • Allow users to choose custom LiteLLM models without manual configuration

Why this matters:

Without this, using LiteLLM as a model gateway breaks the UX:

• No model discoverability
• High friction for users
• Not viable for non-technical users

[adrixgc]

Quick question @iwinux @harshit97

Have any of you managed to get the gateway's /v1/models endpoint to properly populate the model list in the Codex CLI?

In our case, the endpoint returns the custom models correctly, but the CLI doesn’t seem to expose them as selectable options (we still need to manually set the model ID).

Just trying to understand if this is a general limitation or if someone has found a workaround.

Thanks!

[evannotfound]

Just add

requires_openai_auth = true

under your provider.

then, restart the app. if the app asks you to login, choose api key, and enter any character then press enter

this is a workaround

[tranleo148]

Just add

requires_openai_auth = true

under your provider.

then, restart the app. if the app asks you to login, choose api key, and enter any character then press enter

this is a workaround

it worked for me. thanks

[iwinux]

Latest version on macOS (Version 26.406.31014 (1395)) seems to have fixed the issue. Is there any changelog entry confirming this?