PR #20098 breaks project configs for model_providers

[Austinhs]

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: #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.

[Austinhs]

Wow Issue #22222 -- nice.

[github-actions]

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

• Project-local model_provider and model_providers ignored after Windows 26.506.x update #21769

Powered by Codex Action

[Austinhs]

A working fix: Austinhs@49c4a01

• Would remove the test changes. I'm not really sure what codex was smoking when it made that change. I don't think it really makes sense. Removed in 064c74d

[Austinhs]

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

[Austinhs]

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]

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

2. 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.