CLI fails at config load when an unused model_providers entry still sets wire_api = chat (no migration path)

What version of Codex CLI is running?

0.151.0

What subscription do you have?

API key (no ChatGPT subscription)

Which model were you using?

N/A — CLI fails before model selection

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

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

Windows Terminal, PowerShell 5.1.26100.9278

Codex doctor report

{
  "schemaVersion": 1,
  "overallStatus": "fail",
  "codexVersion": "0.151.0",
  "checks": {
    "config.load": {
      "id": "config.load",
      "category": "config",
      "status": "fail",
      "summary": "config could not be loaded",
      "details": {},
      "notes": ["failed to load Codex config"],
      "remediation": "Fix the reported config error, then rerun codex doctor."
    }
  }
}

(truncated to the relevant check; full codex doctor --json available on request)

What issue are you seeing?

A single model_providers.* entry that still uses the removed wire_api = "chat" makes every Codex command fail at config load — even when that provider is not the selected model_provider, and even for commands that need no provider at all (codex login status).

The full error:

Error loading config.toml: `wire_api = "chat"` is no longer supported.
How to fix: set `wire_api = "responses"` in your provider config.
More info: https://github.com/openai/codex/discussions/7782
in `model_providers.token-plan.wire_api`

So an entry that is completely inert (never referenced by model_provider, any profile, or --model) is validated eagerly and hard-fails the whole config. Discussion #7782 announced the removal of chat/completions support, but users upgrading from a release where wire_api = "chat" was the documented value for third-party providers (e.g. OpenAI-compatible gateways, Token Plan / DashScope-compatible endpoints) get a hard brick with no migration path — they have to find the announcement discussion to understand why the CLI stopped starting.

This looks like the same failure class as #24858 and #25440 ("legacy config prevents startup instead of migrating or warning"), now triggered by the wire_api removal.

What steps can reproduce the bug?

Minimal reproduction with an isolated CODEX_HOME (no other state involved), PowerShell on Windows 11:

mkdir C:\Users\USER\codex-repro; cd C:\Users\USER\codex-repro

@'
model = "gpt-5.5"
model_provider = "openai"

[model_providers.token-plan]
name = "Token Plan ModelStudio"
base_url = "https://token-plan.ap-southeast-1.maas.aliyuncs.com/compatible-mode/v1"
wire_api = "chat"
env_key = "TOKENPLAN_API_KEY"
'@ | Out-File -Encoding utf8 config.toml

$env:CODEX_HOME = "$PWD"
codex exec --skip-git-repo-check "Reply with just the word OK"

Result: hard failure with the error above — despite model_provider = "openai" and token-plan never being selected.

Control: changing only wire_api = "chat" → wire_api = "responses" in the same file (leaving everything else identical) lets the same command proceed past config load.

codex login status and codex exec fail identically; only codex doctor runs (and reports config.load: fail).

What is the expected behavior?

1. Unused provider entries should not be able to brick the CLI. If a model_providers.* entry uses a removed value but is not the active provider (and is not referenced by any profile), config loading should at worst warn and skip that entry.
2. If eager validation is kept, the error should include a one-shot migration hint that does not require reading a discussion thread — e.g. run: codex config migrate, or an automatic rewrite to wire_api = "responses" with a notice, similar to other config migrations.
3. The removal note in discussion #7782 could also gain a "what breaks if you upgrade without migrating" section, since this is the state every pre-deprecation third-party-provider user lands in.

Additional information

• Environment: Windows 11 Pro (build 26200), Intel Core (UHD Graphics 620), Node v26.7.0, git 2.55.0.windows.3.
• Real-world config that hit this (redacted keys): top-level model_provider = "bailian-cli" (responses wire API), plus a leftover [model_providers.token-plan] block with wire_api = "chat" from an earlier experiment — never referenced by the active provider. The leftover block alone prevented all CLI use.
• codex doctor --json reports overallStatus: fail due to config.load, which is at least diagnosable — but a user whose first command is codex exec gets no such hint.

Start with the config.load failure reported by codex doctor --json and reproduce it using the isolated CODEX_HOME config.toml shown in the issue. Compare behavior for an unused model_providers.* entry using wire_api = "chat" with the responses control, including codex login status and codex exec. Done means unused legacy entries no longer brick commands, or the CLI provides the agreed migration behavior and guidance.