Custom `model_provider` endpoint is silently ignored when signed into a ChatGPT account — zero requests reach the configured base_url; all sampling goes to the account websocket, with no diagnostic

Reproduce the behavior with the provided CODEX_HOME configuration in both account-signed-in and API-login environments, then inspect transport records for the configured base_url versus account websocket endpoints. Trace provider selection and model-catalog refresh behavior; done when the configured provider is honored or a visible diagnostic explains the precedence and prevents misleading model resolution.

Summary

When a Codex home (CODEX_HOME) is signed into a ChatGPT account, configuring a custom model_provider (e.g. base_url = "https://api.deepseek.com", wire_api = "responses") is silently ignored. Sessions resolve the configured model name, but no request ever reaches the provider's base_url; all sampling traffic goes to the signed-in account's OpenAI websocket (wss://chatgpt.com/backend-api/codex/responses, wss://api.openai.com/v1/responses). No warning, error, or diagnostic indicates the override. The same provider config works correctly in a fresh CODEX_HOME with forced_login_method = "api". This effectively makes custom providers unusable in any account-signed-in environment, with nothing telling the user why.

Repro

Config in an account-signed-in CODEX_HOME:

model = "deepseek-v4-flash"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
wire_api = "responses"

[model_providers.deepseek.auth]
command = "/usr/bin/security"
args = ["find-generic-password", "-a", "codex-deepseek", "-s", "com.xueyanli.codex.deepseek-v4-flash", "-w"]

Expected: sampling requests are POSTed to https://api.deepseek.com/responses.

Observed over the day this config was active (from the app's own logs_2.sqlite transport records):

• requests reaching api.deepseek.com: 0
• requests via wss://chatgpt.com/backend-api/codex/responses: 165
• requests via wss://api.openai.com/v1/responses: 23

The configured model name still resolves (turn_context shows model=deepseek-v4-flash), so the provider setting is not ignored at the model-name level — only at the transport level. There is no log line saying the custom provider was overridden or fell back.

Control: the exact same provider block in a fresh CODEX_HOME with forced_login_method = "api" + preferred_auth_method = "apikey" reaches api.deepseek.com correctly.

Related symptom

With a custom provider configured, the online model-catalog refresh also fails intermittently:

list_models{refresh_strategy=online}: failed to refresh available models: timeout waiting for child process to exit

(observed 100+ times across several days, always while a custom/non-default provider was configured). No surface explains the failure or retries it.

Expected behavior

• Either honor the configured model_provider's base_url regardless of sign-in state, or
• if sign-in must take precedence, log a visible warning such as "custom provider X ignored because account Y is signed in" — and do not resolve the custom model name if it won't be used. Silent transport redirection with a resolved-but-unused provider is the worst failure mode: the session looks like it's using DeepSeek while actually billing/routing through the account.

Environment

• macOS (Darwin 25.5.0)
• ChatGPT desktop app 26.730.61639 (build 6234), embedded Codex runtime cli 0.147.0-alpha.1.2
• model=deepseek-v4-flash, model_provider=deepseek, base_url=https://api.deepseek.com, wire_api=responses

Related: #37237 — a second silent failure of custom-provider handling in the same app build.