›_ Codex Issues
Codex Issues / #40056

Codex automatically changed priority mode without permission, so i lost most of my usage

Open 💬 2 comments Opened Aug 22, 2026 by codernine-moreh
💡 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)?

0.147.0

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.3.0 arm64 arm

What issue are you seeing?

The evidence supports an app/client settings bug—not a user-enabled Fast mode.
What the records show:

  • No /fast, settings action, or user request enabling Fast mode exists.
  • The thread oscillated automatically:
  • 17:12 KST: default → priority
  • 18:16 KST: priority → default
  • 20:07 KST: default → priority
  • Next day 12:11 KST: priority → default
  • Changes occurred only at task boundaries, before ordinary user messages.
  • The final goal ran entirely during the second priority interval.
  • Your persisted configuration currently says service_tier = "default".
  • Both active subagents were also default, so Fast was not inherited from them.

The strongest suspect is client/app state synchronization with version skew:

  • This thread is owned by a long-running Codex app-server 0.144.1 process started August 17.
  • Codex 0.147.0 was subsequently installed, but the old daemon continued serving this thread.
  • The frontend appears to have silently supplied or restored priority for some submissions while the visible/default configuration remained Standard.

What steps can reproduce the bug?

Feedback ID: 01a01e12-f6f4-7792-a869-b98ea71dc7d5

What is the expected behavior?

It should not enable fast mode without user permission. Reset my usage!

Additional information

Thread: 01a01e12-f6f4-7792-a869-b98ea71dc7d5
Issue: service_tier silently oscillated between default and priority
Expected: default; user never enabled Fast mode
Impact: final 11-hour goal ran entirely as priority, consuming approximately
50% of weekly usage
App-server: 0.144.1, while installed Codex was 0.147.0
First unexpected priority event: 2026-08-21 17:12:34 KST
Priority interval covering goal: 2026-08-21 20:07:28 KST through
2026-08-22 12:11:34 KST

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 6 days ago

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

  • #39894

Powered by Codex Action

void0xsasha · 2 hours ago

Independent Windows recurrence observed on 2026-08-28 (Asia/Jerusalem), consistent with this issue and related global/service-tier persistence reports.

Environment / observed behavior:

  • Codex Desktop/Work on Windows, ChatGPT-authenticated account.
  • User reports no intentional Fast activation for this incident.
  • Repository-local .codex/config.toml explicitly pins service_tier = "default" and fast_mode = false.
  • A repository hardening preflight stopped a remediation task with FAST_MODE_BLOCK because the global ~/.codex/config.toml no longer had service_tier = "default".
  • The repository-local config was rechecked after the block and was still explicitly default; the drift was therefore in the user-global Codex config, not the repository.
  • This is a recurrence after the global config had previously been explicitly reset to Standard/default as part of quota hardening.
  • The failure happened at a task boundary before any material remediation work, which is similar to the task-boundary state changes described in this issue.

Why this is concerning:

  • service_tier=priority is the Fast path and can increase usage. A global preference must not silently change because of thread/app state synchronization.
  • Explicit repo-local default is not sufficient protection when the client/preflight separately observes a non-default global tier.

Related open reports that appear relevant:

  • #37666 — Fast mode in one thread also changes the global service tier.
  • #39535 — slash-command settings unexpectedly persist globally.
  • #35136 — Desktop settings serialization can rewrite/drop service_tier.
  • #39894 / #29940 — unexpected priority tier on subagent activity.

I am adding a local guard on this Windows machine that (a) records timestamp, file hash, observed service_tier/fast_mode, Codex process/version metadata when available, and (b) immediately restores top-level service_tier = "default" and [features].fast_mode = false. If the drift repeats, the resulting sanitized event log should provide a precise timestamp series for maintainers.

Current limitation: the detection event did not capture the writer process, so this comment does not claim which component wrote the global file. The evidence supports unexpected global config drift; attribution still needs client/app-server investigation.