›_ Codex Issues
Codex Issues / #22160

CLI /model and Desktop model pickers should expose config profiles / custom provider model aliases

Resolved 💬 4 comments Opened May 11, 2026 by wonderly321 Closed May 11, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Problem

Codex CLI supports custom profiles in ~/.codex/config.toml, and those profiles can encode a complete model selection:

[model_providers.internal-provider]
name = "Internal Provider"
base_url = "https://<internal-provider>/openai/v1"
wire_api = "responses"
http_headers = { ... }

[profiles.internal-gpt55]
model_provider = "internal-provider"
model = "gpt-5.5-2026-04-24"
model_reasoning_effort = "medium"

[profiles.internal-gpt55-high]
model_provider = "internal-provider"
model = "gpt-5.5-2026-04-24"
model_reasoning_effort = "high"

[profiles.internal-gpt55-xhigh]
model_provider = "internal-provider"
model = "gpt-5.5-2026-04-24"
model_reasoning_effort = "xhigh"

These profiles work when starting Codex from the CLI:

codex -p internal-gpt55-xhigh

However, they are invisible in the interactive /model selector. The model selector only shows built-in model catalog entries such as gpt-5.5, gpt-5.4, etc.

The same limitation affects Codex Desktop: custom profiles are not exposed as selectable model entries, so using a custom provider requires changing global config defaults rather than choosing a profile per conversation.

Expected behavior

Config profiles should be selectable as model entries in the CLI /model selector and in the Desktop model picker.

For example, the picker could show:

  • gpt-5.5
  • gpt-5.4
  • internal-gpt55
  • internal-gpt55-high
  • internal-gpt55-xhigh

Selecting internal-gpt55-xhigh should start or switch to a conversation using:

model_provider = "internal-provider"
model = "gpt-5.5-2026-04-24"
model_reasoning_effort = "xhigh"

Why this matters

Many users want to keep the default OpenAI/Codex models for normal conversations, but occasionally use a custom OpenAI-compatible provider for specific conversations.

Profiles are already a good abstraction for this because they can bundle:

  • model_provider
  • model
  • model_reasoning_effort
  • other per-model/per-provider settings, including non-public provider details

But today there is a UX gap:

  • codex -p <profile> works
  • /model does not show <profile>
  • Desktop model picker does not show <profile>

This makes custom provider usage feel like a hidden CLI-only feature, and makes reasoning effort variants hard to discover.

Related issues

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #20635

Powered by Codex Action

wonderly321 · 3 months ago

Thanks for the duplicate pointer. I reviewed #20635, and I think this request is related but not the same.

#20635 asks for an in-session /profile command that can switch profiles without restarting the current session.

This issue is mainly about model/profile discoverability in existing pickers:

  • CLI already supports starting with codex -p <profile>.
  • However, the interactive /model selector does not show config profiles.
  • Desktop model picker also does not show config profiles.
  • This makes custom provider aliases and reasoning-effort variants effectively hidden unless the user knows the exact -p command.

For this issue, preserving the current session is not required. It would already help if profiles appeared as selectable entries when starting or configuring a conversation, for example:

  • internal-gpt55
  • internal-gpt55-high
  • internal-gpt55-xhigh

If the current profile mechanism is going to be replaced, the same UX need probably still applies to the replacement: users need a way to define provider/model/effort aliases and select them from the CLI /model UI and Desktop model picker.

etraut-openai contributor · 3 months ago

We are planning to deprecate profiles soon and replace it with a new mechanism. For that reason, we don't have plans to improve the current mechanism.

smileBeda · 4 days ago

@etraut-openai this isn't about profiles tho
It just happens that right now you have to use profiles to register other models - the core point is, users want to be able to select their custom models with /model.

Thats currently impossible unless we mess with the inbuilt catalog which is likely a bad idea since it expects metadata other models dont provide