[Windows Desktop] Fast mode becomes selected during normal use while config remains Standard

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

26.825.4187.0

What subscription do you have?

ChatGPT personal account (exact plan is not shown in the Codex App)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

During normal use of the Codex Windows desktop app, the UI unexpectedly showed Fast mode as enabled even though I did not intentionally enable it.

This observation does not appear to be tied to an app restart.

Verified local state at the time of investigation:

• service_tier = "default" in the Codex configuration
• no persisted explicit Fast-tier selection in global state
• messages sent to existing tasks did not include a model, reasoning-effort, or service-tier override

This makes the UI-selected Fast state inconsistent with the stored Standard/default configuration. I have not yet isolated the exact triggering action.

What steps can reproduce the bug?

The issue is not reliably reproducible yet.

Observed sequence:

1. Use the Codex Windows desktop app normally with Standard/default service tier configured.
2. Continue existing tasks and send messages to them.
3. At some point during normal use, notice that Fast is selected even though it was not explicitly enabled.

Important: I am not claiming that sending a task message is the cause. The task messages inspected did not carry any model, reasoning, or service-tier override. The trigger is currently unknown.

What is the expected behavior?

The app should remain on Standard/default unless the user explicitly selects Fast. Activating or continuing a task should not change the service tier. The UI and persisted configuration should remain consistent.

Additional information

Related but not identical reports:

• #20856 describes Windows desktop settings persistence/config-version conflicts involving Fast/Standard state.
• #13960 clarifies that exposing Fast mode does not mean automatically enabling it.

App version: 26.825.4187.0

No raw configuration files, databases, project content, or logs are attached. Please let me know which sanitized log events or diagnostics would be most useful to capture if this happens again.

Start with the Windows desktop app's Fast/Standard selection, the persisted service_tier configuration, and global state while continuing existing tasks. Reproduce the unexpected Fast selection if possible and compare the UI with stored state and task messages. Done means the app remains on Standard/default unless Fast is explicitly selected, with consistent UI and persisted configuration.