Codex App resets Speed from Fast to Standard after restart

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #20162

Powered by Codex Action

I don't think this is a strict duplicate of #20162.

#20162 is mainly about the VS Code extension resetting Normal back to Fast after reopen. This issue is about the macOS Codex App resetting an explicit Fast selection back to Standard after app restart.

The local persisted state shows the App had stored:

• default-service-tier = "fast"
• has-user-changed-service-tier = true

After a normal Codex App restart, it rewrote only:

• default-service-tier = null

while has-user-changed-service-tier stayed true and ~/.codex/config.toml still contained service_tier = "fast".

So it may share an underlying service-tier persistence path with #20162, but the observable bug and reproduction are different.

I got the same issue

Do we have a solution to this issue ?

Generally, fast mode is automatically turned off in the following situation.

Turn on Plan Mode and design a plan.

Press Enter on the 'Apply this plan' button.

After that, Codex's fast mode will be turned off.

I can confirm this still reproduces on Windows with:

PackageFullName:
OpenAI.Codex_26.429.8261.0_x64__2p2nqsd0c76g0

Before restart:
default-service-tier = "fast"
has-user-changed-service-tier = true

After restart:
default-service-tier = null
has-user-changed-service-tier = true

The state file was rewritten during app startup. The UI then shows Standard, and logs show:
session handler: service_tier: Some(None)
outgoing request: service_tier: "default"

Ref session: 019dfc81-fe32-7253-aad1-7038e868bf17

I am having the same issue but opposite- Codex sidebar in VSCode defaults to Fast mode every time I open it, even after setting it to Standard via the dropdown, and setting parameters from the docs (https://developers.openai.com/codex/config-basic#supported-features) manually:

service_tier = "flex"

[features]
fast_mode = false

Also, it appears that the /fast command has completely disappeared as of version 0.130.0 in the cli (still do see it in the VSCode extension)

I can reproduce/observe the same class of problem on a newer macOS desktop build.

Environment:

• Codex Desktop: 26.519.41501
• Bundle identifier: com.openai.codex
• macOS: 26.5 (25F71)
• Codex CLI installed locally: codex-cli 0.133.0

Observed state after setting Settings → Speed = Fast and then seeing new chats come up as Normal/Standard after restarting the app:

# ~/.codex/config.toml
service_tier = "fast"
default-service-tier = "priority"

The local model cache maps priority to the UI tier named Fast:

{
  "slug": "gpt-5.5",
  "service_tiers": [
    {
      "id": "priority",
      "name": "Fast",
      "description": "1.5x speed, increased usage"
    }
  ],
  "additional_speed_tiers": ["fast"]
}

But the persisted Electron atom state currently only contains:

has-user-changed-service-tier=true

and no default-service-tier value.

So from the user-facing side, Settings still shows Fast, and ~/.codex/config.toml has default-service-tier = "priority", but after an app restart each newly created chat appears to initialize its Speed selector as Normal/Standard. This looks like the new-chat initialization path is not reading the same persisted setting as the Settings screen, or it is falling back to the missing Electron atom value despite the TOML default being present.

I have this issue as well

Fresh confirmation from another Windows + SSH remote workflow on 2026-05-31.

User-visible behavior: every time Codex is opened, the Speed selector comes back as Normal/Standard instead of preserving the last explicit choice, Fast.

This matters especially for SSH remote projects because the user expects the speed tier to be a persistent app/session preference across app restarts, not something that has to be re-selected for each remote work session.

I did not open a new issue for this because it appears to match this issue's core symptom: an explicit Fast selection is not reliably used when the app initializes new chats after restart.

I added a read-only diagnostic for this exact Speed/Fast persistence shape in trace-to-skill@0.1.67:

npx trace-to-skill@0.1.67 config-audit ~/.codex --format json

It does not dump raw config.toml or raw .codex-global-state.json; it reports only the small state needed for this issue: serviceTier, configDefaultServiceTier, globalDefaultServiceTier, globalHasUserChangedServiceTier, and a service_tier_persistence_drift finding when config requests Fast but global state has default-service-tier = null while has-user-changed-service-tier = true.

I verified the published package from a clean temp install against a minimal repro with service_tier = "fast" and global state default-service-tier: null; it produced service_tier_persistence_drift.

Release: https://github.com/grnbtqdbyx-create/trace-to-skill/releases/tag/v0.1.67

That is one very annoying behavior.
I even reinstalled the UI app completely, wiped all ~/.codex, ~/Library/Application Support/..., ~/Library/Caches/... etc. Did not help.
Please fix or give instructions on how to resolve.

+111111.
it is 2026-06-03, is not fixed yet. why?
please fix this.

Oh my, in the latest update the setting survives after restarts! Thank you! 👏

Finally fixed