›_ Codex Issues
Codex Issues / #23556

Codex mobile and Desktop disagree on Fast mode state

Resolved 💬 3 comments Opened May 19, 2026 by johnpippett Closed May 19, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Version 26.513.31313 (2867)

What subscription do you have?

Not included here; please ask if needed.

What platform is your computer?

macOS Darwin 25.4.0 arm64

What issue are you seeing?

Codex mobile and Codex Desktop do not appear to agree on the Fast mode / Speed setting.

Observed user-visible behavior:

  • In the mobile app, I can set Codex to use Fast mode, and the mobile UI sometimes says Fast mode is enabled.
  • In Codex Desktop, the UI says I am not using Fast mode / shows Standard.
  • It is unclear whether this is only a UI/state sync problem or whether the actual request service tier differs between mobile and Desktop.

Local Desktop state also shows a split source of truth:

# ~/.codex/config.toml
model = "gpt-5.5"
model_reasoning_effort = "medium"
service_tier = "fast"
# ~/.codex/.codex-global-state.json, electron-persisted-atom-state
default-service-tier = null
has-user-changed-service-tier = true
has-seen-fast-mode-announcement = true
has-seen-fast-mode-home-banner = true
fast-mode-personalized-estimate = { estimatedSavedMs: 9280002, rolloutCountWithCompletedTurns: 94, computedAtMs: 1779163536400 }
codex-mobile-has-connected-device = true

That state matches the Desktop UI showing Standard/off even though config.toml still requests service_tier = "fast" and mobile has been set to Fast.

What steps can reproduce the bug?

  1. Connect/use Codex from the mobile app and Codex Desktop on the same account / connected device setup.
  2. In the mobile app, set Codex Speed/Fast mode to Fast.
  3. Open Codex Desktop.
  4. Observe the Desktop Speed/Fast mode UI.
  5. Check local Desktop state:
  • ~/.codex/config.toml contains service_tier = "fast"
  • ~/.codex/.codex-global-state.json has electron-persisted-atom-state.default-service-tier = null
  1. The mobile UI and Desktop UI do not present the same Fast mode state.

What is the expected behavior?

One of these should be true:

  • Fast mode is an account/connected-device preference and mobile/Desktop should show the same current state.
  • Fast mode is intentionally per-client/per-device, and the UI should make that explicit.
  • If Desktop cannot determine the effective service tier, it should show an explicit unknown/unsupported state rather than confidently showing Standard/off.

Also, Desktop should expose the actual effective service tier for the current turn so users can tell whether they are using Fast mode or only seeing stale UI state.

Additional information

This may overlap with the Desktop persistence/config drift class of bugs, but the mobile/Desktop disagreement makes it hard to know the real effective state.

Related issues found before filing:

  • #20769: Codex App resets Speed from Fast to Standard after restart
  • #14689: Codex App is misreporting the state of /fast mode
  • #17772 / #22028: Fast mode disappeared from Codex App / CLI UI

The key difference here is the cross-client symptom: mobile can show Fast while Desktop shows Standard/off for what appears to be the same connected Codex setup.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #22691

Powered by Codex Action

maltbae · 3 months ago

This is a consistency problem that erodes trust in the tool. If 'fast mode' means different things depending on which interface you're using, you can't rely on it as a developer — you end up double-checking both clients every time.

The underlying issue is that mobile and desktop are maintaining separate state for what should be the same feature flag. This is the kind of inconsistency that makes teams revert to synchronous human review instead of trusting the AI.

One way to mitigate this while waiting for a fix: make your mode preference explicit in your workflow rather than relying on the UI state. For example, if you're using Codex in a team context, document which mode you're running in the project README so both clients stay aligned.

For the long-term fix: if the fast/slow toggle was stored server-side on the account rather than client-side in each app's local state, this inconsistency couldn't happen. +1 for this being a real workflow blocker.

johnpippett · 3 months ago

Additional local evidence from the same Desktop setup:

I just discovered this while trying to understand why usage was being consumed faster than expected. The visible composer UI showed only 5.5 Medium and did not indicate Fast mode or any effective Speed/service-tier state. However, local config still contained:

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

Because the UI did not surface Fast mode in the composer control, it was not obvious whether the current turn was using Fast, Standard, or stale config. That makes the split source of truth more than cosmetic: a user can burn through usage while believing they are only looking at model/reasoning settings.

I removed the hidden config flag as a local workaround. After removal, the relevant config became:

model = "gpt-5.5"
model_reasoning_effort = "medium"

Expected behavior: Desktop should make the effective service tier visible for the current turn, or clearly warn when ~/.codex/config.toml contains a service tier that differs from the Desktop UI state. If the config value is ignored, the UI/logs should say so. If it is honored, the composer/settings UI should expose that clearly.