[Windows] Regression: resumed threads show Standard while still using Fast and rewrite service_tier

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.8289.0

What subscription do you have?

ChatGPT Pro (20x plan)

What platform is your computer?

Microsoft Windows 11 Pro 10.0.26200 x64

What issue are you seeing?

On Codex Desktop 26.818.8289.0, new threads respect service_tier = "fast" and initially display Fast mode. However, reopening an existing thread that was set to Fast displays Standard mode.

This appears to be a UI/state normalization bug rather than the request actually falling back to Standard:

• The resumed thread's latest local thread_settings_applied event contains service_tier: "priority".
• OpenAI's API documentation states that Fast requests are served/reported as priority.
• Despite the effective thread tier being priority (Fast), the resumed-thread UI displays Standard.
• Selecting Fast again in that resumed thread rewrites the top-level config from service_tier = "fast" to service_tier = "priority".
• After that rewrite, the global Fast default can also display as Standard after another restart until the config is manually changed back to fast.

This is a recurrence of the behavior reported in #37026 / #37069, which was marked fixed on August 10, 2026, but now reproduces again on a newer Windows build.

What steps can reproduce the bug?

1. Set %USERPROFILE%\.codex\config.toml to service_tier = "fast".
2. Start Codex Desktop and create a new thread. Confirm that it defaults to Fast.
3. Open an existing thread that previously used Fast.
4. Close and reopen the app, then resume that existing thread.
5. Observe that the UI displays Standard.
6. Inspect the thread rollout: the latest thread_settings_applied event still reports service_tier: "priority" (the effective Fast tier).
7. Select Fast in the resumed thread.
8. Inspect config.toml: the app has rewritten the top-level value from fast to priority.
9. Change it back to fast; new threads display Fast again, but selecting Fast in a resumed old thread repeats the rewrite.

No session IDs, prompts, or user data are required to reproduce this.

What is the expected behavior?

• A resumed thread using the effective Fast/priority tier should display Fast, not Standard.
• The desktop app should normalize fast and priority consistently.
• Selecting Fast in an existing thread should not rewrite the canonical persistent configuration into a value that the UI later interprets as Standard.
• New and resumed threads should preserve the same Fast-mode state across restarts.

Additional information

Environment:

• Codex Desktop: 26.818.8289.0
• Platform: Windows 11 Pro 10.0.26200, x64
• Model observed: gpt-5.6-sol
• Related issues: #37026, #37069, #20769
• Fast/priority API behavior: https://developers.openai.com/api/reference/cli/resources/responses/methods/create

The issue seems to involve using priority as the runtime/service catalog ID while fast is the persistent config/UI alias. The resumed-thread path appears to preserve the former but fail to map it back to the Fast UI state, and then writes the runtime ID back to the global config.

Start by reproducing the resumed-thread flow on Windows and compare the latest thread_settings_applied event with %USERPROFILE%.codex\config.toml. Trace how the effective priority tier maps to the Fast UI state and how selecting Fast rewrites the configuration. Done means resumed and new threads consistently display Fast, and selecting Fast does not rewrite the canonical setting to priority.