Regression: Fast mode in one thread also changes the global service tier

Open 💬 0 comments Opened Aug 9, 2026 by hhushhas

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

26.803.41515

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

Selecting Fast mode inside one existing Codex App thread also rewrites the top-level service_tier in ~/.codex/config.toml. The global value then affects unrelated threads that should remain on Standard.

The selected thread does receive its own thread setting. The bug is that the same action also changes the global default.

This appears to be a regression or incomplete fix for #19982. That issue was closed as completed on August 5 with the note: “Speed/service-tier settings are stored per conversation.” The current August 8 build still changes both scopes.

What steps can reproduce the bug?

  1. Set the top-level Codex config to service_tier = "default".
  2. Open two existing Codex App threads, A and B.
  3. In thread A, change Speed from Standard to Fast.
  4. Observe that thread A changes to Fast as expected.
  5. Observe that ~/.codex/config.toml also changes its top-level service_tier to Fast.
  6. Switch to thread B or send another turn there. Thread B can now inherit Fast even though its speed was never changed.

This is especially costly when thread A is a small task but thread B is a large, long-running task that should stay on Standard.

What is the expected behavior?

Changing Speed inside an existing thread should update only that thread. It should not write the global service_tier default.

The global default can remain available for new threads, but it should have a separate control. Changing that default should not alter existing threads.

Additional information

  • Related completed issue: #19982
  • Codex CLI bundled/runtime version: 0.147.0
  • The official config reference describes service_tier as the preferred tier for new turns and separately defines models.new_thread.service_tier as a new-thread default: https://learn.chatgpt.com/docs/config-file/config-reference
  • Inspection of the packaged desktop handler shows that an existing-thread selection calls the per-thread settings update and then also calls the global config writer when the selected tier differs from the current default. The second call is the scope leak.

A minimal fix is to call the global writer only when there is no existing conversation. Existing conversations should use only thread/settings/update.

View original on GitHub ↗