TUI converts an unsupported service_tier to default before core can emit its warning #52840

Environment and scope

• Codex CLI 0.162.1 on Windows x64.
• Source commit: 092d3acd6bec3e3a14bdc7e7a2810ab628ab759d.
• The relevant resolver and warning function bodies were also identical in inspected main commit 806d9732c974bc8a51b8317c1bd8985544fe627c.
• This report concerns diagnostic preservation, independently of whether a model should support Ultrafast.

Problem
When an explicitly configured service tier is absent from the model catalog, the TUI can replace the requested value with default before starting the core session. Core already has an unsupported-tier warning, but that warning no longer receives the original unsupported value.

With Sol advertising only priority, requesting ultrafast therefore has this source-level path:

configured: ultrafast
TUI effective_service_tier: None
TUI service_tier_update_for_core: Some(Some("default"))
session config received by core: default
unsupported_service_tier_warning: None

Source evidence

1. effective_service_tier returns None for an unsupported explicit tier.
2. service_tier_update_for_core returns an explicit default for this case when speed features are enabled and the model is known.
3. session_config_with_effective_service_tier writes that value into the session configuration.
4. unsupported_service_tier_warning explicitly excludes default, so the original reason is lost. Core calls this warning during startup.

Reproduction and validation
Fixture:

• Known model: gpt-6.1-sol.
• Advertised service tiers: ["priority"].
• Both speed features enabled.
• Explicit configured tier: ultrafast.

Using the exact production function bodies with minimal type scaffolding, a local Rust harness confirmed:

• Calling the core warning with the original ultrafast value produces a warning.
• Calling it with the TUI-normalized default value produces no warning.
• Advertising ultrafast preserves it through the existing resolvers.
• Standard, priority, flex, unknown-tier, and disabled-feature controls retain their expected behavior.

Result: 8 passed; 0 failed, compiled with rustc 1.93.0.

This was an extracted-function reproduction, not the repository's test suite or a full TUI integration test. Separately, real interactive CLI runs with and without the shared daemon completed while recording feedback_tags.service_tier=default. Those runs corroborate the fallback, but do not by themselves establish that every user-facing warning was absent.

Requested fix
Preserve the original requested value for diagnostics, or emit the rejection warning before TUI normalization. The message should identify:

• the requested model and tier;
• the effective tier;
• whether the reason is missing model support or a disabled feature/policy.

Please retain the existing model-support and managed-policy checks. This is not a request to force unsupported tiers through.

Suggested regression coverage

• Unsupported explicit tier produces a visible, specific warning on the normal TUI startup path.
• Supported explicit tier is preserved without a spurious warning.
• Explicit Standard remains Standard, even if a catalog default is faster.
• Feature/policy restrictions remain enforced and are distinguished from missing catalog support.

Catalog eligibility is a separate issue; this warning path should work even when rejecting the tier is correct.