codex - 💡(How to fix) Fix Codex App resets Speed from Fast to Standard after restart [3 comments, 3 participants]

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

Version 26.429.30905 (2345)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

macOS 26.4.1 (25E253), arm64

What issue are you seeing?

Codex App resets the Speed setting from Fast back to Standard after a normal app restart.

This happens even when:

• I explicitly selected Fast in the Codex App UI before restarting.
• ~/.codex/config.toml still contains service_tier = "fast".
• ~/.codex/.codex-global-state.json still has electron-persisted-atom-state.has-user-changed-service-tier = true.

The specific state change I observed is:

# Before restarting Codex App, immediately after selecting Speed = Fast
~/.codex/.codex-global-state.json:
  electron-persisted-atom-state.default-service-tier = "fast"
  electron-persisted-atom-state.has-user-changed-service-tier = true

~/.codex/config.toml:
  service_tier = "fast"

# After quitting and reopening Codex App, without updating the app
~/.codex/.codex-global-state.json:
  electron-persisted-atom-state.default-service-tier = null
  electron-persisted-atom-state.has-user-changed-service-tier = true

~/.codex/config.toml:
  service_tier = "fast"

In the UI, default-service-tier = null corresponds to Standard, so the user-visible Speed setting changes back to Standard after restart.

This is not just config.toml being ignored initially. The App UI successfully writes default-service-tier = "fast" when I choose Fast, but the next app launch writes it back to null.

What steps can reproduce the bug?

1. Open Codex App on macOS.

2. Set Speed to Fast in the App UI.

3. Verify local state:

   ~/.codex/.codex-global-state.json:
     electron-persisted-atom-state.default-service-tier = "fast"
     electron-persisted-atom-state.has-user-changed-service-tier = true

4. Quit Codex App.

5. Reopen Codex App.

6. Observe that Speed is now shown as Standard.

7. Verify local state again:

   ~/.codex/.codex-global-state.json:
     electron-persisted-atom-state.default-service-tier = null
     electron-persisted-atom-state.has-user-changed-service-tier = true

What is the expected behavior?

If the user explicitly selects Fast in the Codex App UI, a normal app restart should preserve that choice.

default-service-tier should remain "fast", especially when has-user-changed-service-tier is already true.

Additional information

A concrete local repro from my machine:

Before restart:
  time: 2026-05-02 18:10:47 CST
  default-service-tier = fast
  has-user-changed-service-tier = true
  config.toml service_tier = "fast"
  .codex-global-state.json modified at 18:10:30

After restart:
  time: 2026-05-02 18:11:44 CST
  Codex App process started at 18:11:06
  .codex-global-state.json modified at 18:11:29
  default-service-tier = null
  has-user-changed-service-tier = true
  config.toml service_tier = "fast"

Relevant config:

model = "gpt-5.5"
model_reasoning_effort = "xhigh"
service_tier = "fast"

This appears related to, but not exactly the same as, earlier Fast/config drift reports:

• #14689 reported Codex App misreporting /fast state from config.toml, but that issue is closed and did not show the App UI writing default-service-tier = "fast" and then resetting it to null on restart.
• #18841 reported Fast mode disappearing from settings/chat, but it is also closed and not the same concrete persistence regression.
• #15853 is about the VS Code extension clearing service_tier before a turn, not the macOS App resetting its persisted UI Speed setting on launch.
• #19230 discusses service_tier: null semantics and Fast defaults, but this report is specifically about an explicit user-selected Fast preference being overwritten on app restart.

My hypothesis is that the app startup/default-tier synchronization path may be clearing default-service-tier to null when a transient Fast eligibility check returns false, without respecting has-user-changed-service-tier = true. If so, the startup path should avoid overwriting an explicit user preference unless Fast is definitively unavailable and the UI explains that to the user.