›_ Codex Issues
Codex Issues / #22222

PR #20098 breaks project configs for model_providers

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

What version of Codex CLI is running?

codex-cli 0.130.0

What subscription do you have?

API & Pro

Which model were you using?

5.4

What platform is your computer?

Linux 6.6.114.1-microsoft-standard-WSL2 x86_64 x86_64 (Using WSL)

What terminal emulator and version are you using (if applicable)?

Windows Terminal

What issue are you seeing?

⚠ Ignored unsupported project-local config keys in /home/.../.../.../{repo}/.codex/config.toml: model_provider, model_providers. If you want these settings to apply, manually set them in your user-level config.toml.

Caused by PR: https://github.com/openai/codex/pull/20098

What steps can reproduce the bug?

Run codex within a repo with local .codex/config.toml setup.

What is the expected behavior?

To use repo specific LiteLLM model, but instead it errors and then falls back to default openai route

Additional information

This affects many local repo configurations. These should remain as a project configuration -- especially for people who work at multiple companies and use multiple configurations. At a bare minimum, we should be able to specify what provider to use in the project otherwise, this configuration is useless and should be removed from the documentation.

View original on GitHub ↗

6 Comments

Austinhs · 2 months ago

Wow Issue #22222 -- nice.

github-actions[bot] contributor · 2 months ago

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

  • #21769

Powered by Codex Action

Austinhs · 2 months ago

A working fix: https://github.com/Austinhs/codex/commit/49c4a01ec3f8d9763f13ef35d3f58f812f6491fc

Austinhs · 2 months ago

Mentioning the contributors to PR #20098 to provide context on why this should be excluded.
@owenlin0 @bolinfest

Austinhs · 2 months ago

Related issues open from a quick scan #22205 , #21769 , also seeing many issues open that are showing model_providers likely in repo-specific configurations, I imagine those people are experiencing issues as well with latest update

pmi-copilot · 2 months ago

Confirmed on plain Codex CLI on Windows with Azure OpenAI custom providers.

In my case this affects repo-local profile / profiles as well as model_provider / model_providers.

Environment

  • codex-cli 0.130.0
  • Microsoft Windows NT 10.0.26100.0 x64
  • PowerShell 7.6.0 in the VS Code integrated terminal
  • Azure OpenAI custom provider via AZURE_OPENAI_API_KEY

Repro

  1. In a repo, create .codex/config.toml like this:
profile = "azure-gpt54"

[profiles.azure-gpt54]
model = "gpt-5.4"
model_provider = "azure-openai"
model_reasoning_effort = "medium"

[model_providers.azure-openai]
name = "Azure OpenAI"
base_url = "base-url/openai/v1"
env_key = "AZURE_OPENAI_API_KEY"
wire_api = "responses"
supports_websockets = false
request_max_retries = 4
stream_max_retries = 10
stream_idle_timeout_ms = 300000
  1. In the same PowerShell session, set AZURE_OPENAI_API_KEY to a valid Azure OpenAI key and run:
codex exec --json --ephemeral "say hi"

Actual behavior

  • Codex ignores the repo-local config for provider/profile selection.
  • It falls back to the default OpenAI route instead of the repo-local Azure provider.
  • In my repro, the request goes to https://api.openai.com/v1/responses instead of the configured Azure base URL.
  • The working workaround is to move the provider definition to user-level config and run Codex with an explicit profile, for example codex -p azure-gpt54 ....

Expected behavior

  • Project-local .codex/config.toml should be able to control provider selection for that repo.
  • If this is intentionally no longer supported, the docs should state it clearly and provide a supported per-project alternative.

Additional note

  • The same Azure provider works when configured at user level and explicitly selected with -p azure-gpt54.
  • That suggests the Azure provider definition itself is fine, and the regression is specifically that project-local provider routing is being ignored.