Regression: Fast mode in one thread also changes the global service tier
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?
- Set the top-level Codex config to
service_tier = "default". - Open two existing Codex App threads, A and B.
- In thread A, change Speed from Standard to Fast.
- Observe that thread A changes to Fast as expected.
- Observe that
~/.codex/config.tomlalso changes its top-levelservice_tierto Fast. - 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_tieras the preferred tier for new turns and separately definesmodels.new_thread.service_tieras 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.