What version of the Codex App are you using (From “About Codex” dialog)?
Windows app version reported after update: 26.506.21252
Local package currently observed via PowerShell:
Name : OpenAI.Codex
Version : 26.506.2212.0
PackageFullName : OpenAI.Codex_26.506.2212.0_x64__2p2nqsd0c76g0
Bundled/current CLI:
codex-cli 0.129.0-alpha.15
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Windows x64
What issue are you seeing?
After installing the 26.506.x Windows Codex app update, project-local config.toml model provider settings are ignored. A repository-local .codex/config.toml that previously routed this PHI-sensitive project through a private UW LiteLLM gateway is no longer honored for provider selection.
The project-local config contains:
model_provider = "litellm"
model = "gpt-5.5"
service_tier = "fast"
model_reasoning_effort = "low"
[model_providers.litellm]
name = "UW LiteLLM"
base_url = "https://litellm.dlmp.uw.edu/v1"
env_key = "UW_LITELLM_API_KEY"
wire_api = "responses"
Running Codex CLI from that project now emits this warning:
Ignored unsupported project-local config keys in C:\Users\sayre\Codex\Case Reviewer\.codex\config.toml: model_provider, model_providers. If you want these settings to apply, manually set them in your user-level config.toml.
A tiny CLI request from the same project confirmed it did not use LiteLLM. With request debug logging enabled:
$env:RUST_LOG='codex_core::client=debug,reqwest=debug'
codex exec --json "Return exactly: OK"
The request succeeded, but debug logs showed connections to the OpenAI/ChatGPT gateway:
DEBUG reqwest::connect: starting new connection: https://chatgpt.com/
DEBUG reqwest::connect: starting new connection: https://ab.chatgpt.com/
This is a significant regression for projects that intentionally use project-local provider routing, especially PHI or enterprise repositories that must route through an approved private gateway instead of the default ChatGPT/OpenAI service.
What steps can reproduce the bug?
-
On Windows, install/update Codex App to the 26.506.x release.
-
In a trusted project, create .codex/config.toml with a project-local provider:
model_provider = "litellm"
model = "gpt-5.5"
[model_providers.litellm]
name = "UW LiteLLM"
base_url = "https://litellm.dlmp.uw.edu/v1"
env_key = "UW_LITELLM_API_KEY"
wire_api = "responses"
-
Ensure the user-level ~/.codex/config.toml has a different/global provider, for example model_provider = "openai".
-
From inside the project directory, run:
$env:RUST_LOG='codex_core::client=debug,reqwest=debug'
codex exec --json "Return exactly: OK"
-
Observe the warning that model_provider and model_providers are ignored in project-local config.
-
Observe the request going to https://chatgpt.com/ / https://ab.chatgpt.com/ rather than the configured project-local LiteLLM base_url.
What is the expected behavior?
Project-local .codex/config.toml should be able to set both:
model_provider = "litellm"
and the corresponding provider definition:
[model_providers.litellm]
base_url = "https://litellm.dlmp.uw.edu/v1"
When Codex is launched from that project, requests should route through the project-local provider configuration.
If provider routing from project-local config is intentionally unsupported, Codex should document this as a breaking behavior change and provide a safe alternative for enterprise/PHI projects that require per-project provider routing.
Additional information
I checked the official Codex changelog before filing this and did not find an intentional behavior-change note for this regression.
Observed changelog search results:
26.506.21252: 0 matches
26.506: 0 matches
model setting: 0 matches
config.toml: 11 matches
model picker: 2 matches
project-local: 1 match
The relevant config.toml changelog snippets describe setting a default model via config and model-picker updates, but I did not find a note saying that project-local model_provider or [model_providers.*] would stop being supported.
This behavior is related to config precedence and provider routing. The new warning makes the behavior explicit:
Ignored unsupported project-local config keys ... model_provider, model_providers
Impact:
- Project-local model/provider routing no longer works.
- A PHI-sensitive project can unexpectedly route to the global/default OpenAI gateway instead of an approved private LiteLLM gateway.
- The suggested workaround, moving provider settings to user-level config, is not equivalent because provider choice often needs to vary by project/repository.
What version of the Codex App are you using (From “About Codex” dialog)?
Windows app version reported after update: 26.506.21252
Local package currently observed via PowerShell:
Bundled/current CLI:
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Windows x64
What issue are you seeing?
After installing the 26.506.x Windows Codex app update, project-local
config.tomlmodel provider settings are ignored. A repository-local.codex/config.tomlthat previously routed this PHI-sensitive project through a private UW LiteLLM gateway is no longer honored for provider selection.The project-local config contains:
Running Codex CLI from that project now emits this warning:
A tiny CLI request from the same project confirmed it did not use LiteLLM. With request debug logging enabled:
The request succeeded, but debug logs showed connections to the OpenAI/ChatGPT gateway:
This is a significant regression for projects that intentionally use project-local provider routing, especially PHI or enterprise repositories that must route through an approved private gateway instead of the default ChatGPT/OpenAI service.
What steps can reproduce the bug?
On Windows, install/update Codex App to the 26.506.x release.
In a trusted project, create
.codex/config.tomlwith a project-local provider:Ensure the user-level
~/.codex/config.tomlhas a different/global provider, for examplemodel_provider = "openai".From inside the project directory, run:
Observe the warning that
model_providerandmodel_providersare ignored in project-local config.Observe the request going to
https://chatgpt.com//https://ab.chatgpt.com/rather than the configured project-local LiteLLMbase_url.What is the expected behavior?
Project-local
.codex/config.tomlshould be able to set both:and the corresponding provider definition:
When Codex is launched from that project, requests should route through the project-local provider configuration.
If provider routing from project-local config is intentionally unsupported, Codex should document this as a breaking behavior change and provide a safe alternative for enterprise/PHI projects that require per-project provider routing.
Additional information
I checked the official Codex changelog before filing this and did not find an intentional behavior-change note for this regression.
Observed changelog search results:
The relevant
config.tomlchangelog snippets describe setting a default model via config and model-picker updates, but I did not find a note saying that project-localmodel_provideror[model_providers.*]would stop being supported.This behavior is related to config precedence and provider routing. The new warning makes the behavior explicit:
Impact: