Connecting Ollama in Codex App writes top-level model_provider + model_catalog_json, hiding OpenAI models and causing 404s for gpt-5.5

Open 💬 4 comments Opened Jul 3, 2026 by umminuriddingreen

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex is running?

codex-cli 0.142.5 / Codex App 26.623.81905 (macOS)

What issue are you seeing?

Connecting the Codex desktop app to Ollama persists top-level keys into ~/.codex/config.toml:

model_provider = "ollama-launch-codex-app"
model_catalog_json = "/Users/ummi/.codex/ollama-launch-models.json"

These globally hijack every subsequent Codex session (CLI and app), not just the Ollama one:

OpenAI models disappear from the model picker. When model_catalog_json is set, load_model_catalog (codex-rs/core/src/config/mod.rs) replaces the catalog, and the TUI picker (codex-rs/tui/src/chatwidget/model_popups.rs, try_list_models()) lists only catalog entries — so only Ollama models are selectable and gpt-5.5/gpt-5.4 etc. vanish.
404s against localhost. model = "gpt-5.5" is still set while the default provider is now Ollama, so requests go to http://127.0.0.1:11434/v1/responses and fail with 404 model 'gpt-5.5' not found. This appears to be the root cause behind #30647 / #29703 / #29848, and is related to the picker filtering in #19694.

Notably the app also writes a correct scoped [profiles.ollama-launch] with model_provider = "ollama-launch" — the top-level writes are redundant with it and are what causes the breakage.

What steps can reproduce the bug?

Have a working OpenAI-authenticated Codex setup.
In the Codex app, connect to Ollama (launch/connect local models flow).
Inspect ~/.codex/config.toml: top-level model_provider and model_catalog_json now point at Ollama.
Start a new Codex session: the model picker no longer shows OpenAI models; selecting/keeping gpt-5.5 yields 404 Not Found: model 'gpt-5.5' not found from 127.0.0.1:11434.

What is the expected behavior?

Connecting a local provider should be additive, not a global takeover:

The Ollama flow should scope its settings to the profile it already creates ([profiles.ollama-launch]) instead of writing top-level model_provider / model_catalog_json.
Alternatively (or additionally), when model_catalog_json is set, the picker should merge the custom catalog with the built-in OpenAI presets (or scope the catalog to its provider) rather than replacing them, so users can switch back without hand-editing config.toml.
If the default provider is switched, model should be remapped to a model that exists on that provider rather than left pointing at gpt-5.5.

Workaround

Delete the two top-level lines (model_provider = "ollama-launch-codex-app", model_catalog_json = ...) from ~/.codex/config.toml; the Ollama profile keeps working via codex --profile ollama-launch.

Additional information

Happy to submit a PR for the merge-instead-of-replace behavior in the catalog/picker path if maintainers agree with the direction.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 1 month ago

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

#30647
#30885

Powered by Codex Action

WonJaekuk · 23 days ago

I can reproduce the same user-impact on a newer macOS build:

Codex App: 26.727.51351
bundled Codex runtime: 0.146.0-alpha.9.2
Ollama: 0.32.5
target model: deepseek-v4-flash:0731-cloud

After using the documented Codex App / Ollama flow, the app became an Ollama-only experience: OpenAI account models were no longer available in the picker, the normal composer model display disappeared, and returning to the OpenAI setup required manual configuration recovery. This is especially risky because the user-level config is shared by the ChatGPT-integrated app and local Codex.

Could Codex App support a first-class, per-thread provider selection model that:

keeps the ChatGPT/OpenAI catalog and account access intact,
scopes an Ollama model catalog to that provider rather than replacing the global catalog,
preserves existing OpenAI threads as OpenAI threads, and
provides a reliable in-app return to the OpenAI default?

The current global-provider behavior makes the documented custom-provider capability unsuitable for users who need to alternate between their ChatGPT subscription and Ollama Cloud/local models.

wilylansapp · 7 days ago

User feedback: this behavior is extremely surprising and should not happen automatically.

I installed/downloaded Codex because I want to use Codex/OpenAI models. Connecting Ollama should be an additive, explicitly scoped option — it should not silently replace the global model_provider / model_catalog_json and make OpenAI models disappear from the picker.

From a UX perspective this feels destructive: the user enables a local provider, then Codex itself appears "broken" until they discover they must manually edit ~/.codex/config.toml. Most users will not understand that Ollama modified a global Codex setting behind the scenes.

Expected behavior should be one of:

keep OpenAI as the global/default provider and create Ollama only as a profile; or
explicitly ask the user before changing the global provider/catalog; and
never replace the built-in OpenAI catalog merely because a local provider was connected.

A local-provider integration should be opt-in and reversible from the UI, not a silent global takeover.

claell · 5 days ago

This matches why guided setups that rewrite top-level model_provider and model_catalog_json feel risky, and why additive flows matter.

We are building a small local provider manager that adds [model_providers.*] entries additively with backup and dry-run preview instead of overwriting the top-level selection or replacing the whole catalog. The hiding of built-in OpenAI models described here is exactly the failure mode that approach tries to avoid.

Cross-referencing #29156 (Desktop custom-provider usability) and #36532 (additive/API-key-scoped catalog mechanism).