Custom provider display name silently controls remote compaction capability

What version of Codex CLI is running?

codex-cli 0.152.1

What subscription do you have?

ChatGPT subscription (OAuth)

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Darwin 25.1.0 arm64 arm

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

iTerm2

Codex doctor report

Not included; this is a deterministic provider capability/configuration issue and requires no thread data.

What issue are you seeing?

A custom provider's user-configurable name field is currently treated as a protocol capability switch. ConfiguredModelProvider::capabilities() enables RemoteCompactionSupport::V2 only when ModelProviderInfo::is_openai() returns true, and is_openai() is a strict self.name == "OpenAI" comparison.

This makes a display-looking field behaviorally significant. A typo, localization, or a generated descriptive name silently disables remote compaction while ordinary Responses calls keep working. There is no configuration error or diagnostic explaining why Local Compact was selected.

A real example is Headroom's current Codex initializer, which generates name = "Headroom init proxy": headroomlabs-ai/headroom#3407.

Current source still has the behavior:

• https://github.com/openai/codex/blob/rust-v0.152.1/codex-rs/model-provider-info/src/lib.rs#L467-L469
• https://github.com/openai/codex/blob/rust-v0.152.1/codex-rs/model-provider/src/provider.rs#L353-L360
• Current main: https://github.com/openai/codex/blob/1bc8fb16ae53512c0c7723a436e4b11be81ad4a8/codex-rs/model-provider/src/provider.rs#L348-L366

The visible symptom after Local Compact succeeds is:

Heads up: Long threads and multiple compactions can cause the model to be less accurate. Start a new thread when possible to keep threads small and targeted.

That warning does not identify the provider-name capability decision.

What steps can reproduce the bug?

1. Configure an OpenAI-compatible proxy that supports /responses and /responses/compact:

model_provider = "headroom"

[model_providers.headroom]
name = "Headroom init proxy"
base_url = "http://127.0.0.1:8787/v1"
wire_api = "responses"
supports_websockets = true
requires_openai_auth = true

2. Start Codex 0.152.1 and verify ordinary model requests work through the proxy.
3. Trigger compaction. The provider is classified as RemoteCompactionSupport::Unsupported, so Codex uses Local Compact.
4. Change only name to the exact value OpenAI, restart Codex, and the same provider becomes eligible for Remote Compact v2.

The issue is deterministic in the capability code and does not depend on a particular thread.

What is the expected behavior?

Provider display name should not silently determine protocol capabilities.

Preferred fix: add an explicit provider capability such as:

[model_providers.headroom]
name = "Headroom"
remote_compaction = "v2" # or "auto" / "disabled"

Keep auto as the backward-compatible default for built-in OpenAI/Azure providers, validate that v2 requires the Responses wire API, and emit a clear warning when a custom provider uses Local Compact because remote compaction is not enabled.

At minimum, configuration loading should warn that the custom provider is being treated as remote-compaction unsupported instead of requiring users to rename third-party providers to OpenAI.

Additional information

Related but not duplicate:

• #37010 requests configurable remote compaction per model/provider. This report focuses on the current bug: a display field is an undocumented strict capability gate, and wrong values silently change behavior.
• #38930 reports remote-compaction routing/continuity behavior after provider changes.
• #22042 concerns providers that do not implement the compact endpoint and fallback behavior.

Headroom's corresponding generator bug: headroomlabs-ai/headroom#3407.

Start with codex-rs/model-provider-info/src/lib.rs around ModelProviderInfo::is_openai() and codex-rs/model-provider/src/provider.rs around ConfiguredModelProvider::capabilities(). Reproduce the configuration with a custom provider name, then verify that remote-compaction capability no longer depends on the display name, v2 requires the Responses wire API, and unsupported fallback produces a clear warning.