Codex Desktop ignores config.toml default model (gpt-5.4) and sends gpt-5.3-codex via OverrideTurnContext
What version of the Codex App are you using (From “About Codex” dialog)?
26.325.31654 (1272)
What subscription do you have?
Key-based Auth (AOAI)
What platform is your computer?
Darwin 25.3.0 arm64 arm
What issue are you seeing?
Description
I configured the default model as gpt-5.4 in config.toml, but when a new thread starts, Codex Desktop sends an OverrideTurnContext that uses gpt-5.3-codex from threads.model in the thread database. As a result, the configured default model is overridden and requests are sent to gpt-5.3-codex. With the exact same configuration, Codex CLI works as expected and correctly uses gpt-5.4; the issue only occurs in Codex Desktop.
Actual Behavior
1/ App tries to call gpt-5.3-codex on startup/new thread.
2/ Request fails with 401 because my key is not allowed to access gpt-5.3-codex.
Evidence
1/ state_5.sqlite: threads.model is written as gpt-5.3-codex in newly created threads.
2/ logs_1.sqlite / logs_1.sqlite-wal: OverrideTurnContext ... Settings { model:"gpt-5.3-codex" }.
3/ Screenshot attached: shows 401 and attempted model gpt-5.3-codex.
<img width="2018" height="1382" alt="Image" src="https://github.com/user-attachments/assets/e95591b3-76f1-462a-b9d8-637248cdef51" />
What steps can reproduce the bug?
1/ Configure config.toml with default model gpt-5.4 (same config also works in Codex CLI).
2/ Launch CodexDesktop.
3/ Create a new thread (or open one of the newly created threads).
4/ Send any message to start a new turn.
5/ Observe the request fails, and the error/log shows the app tried gpt-5.3-codex instead of gpt-5.4.
6/ Check local DB/log evidence:
- state_5.sqlite → threads.model for new threads is gpt-5.3-codex
- logs_1.sqlite / logs_1.sqlite-wal → OverrideTurnContext ... Settings { model:"gpt-5.3-codex" }
What is the expected behavior?
App should honor config.toml default model (gpt-5.4) for new turns, or at least not silently override it with stale threads.model values.
Additional information
_No response_
8 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Yes, this behavior is intended. In a GUI-based client like the app, the model for the thread is specified by the controls in the UI.
@etraut-openai Thanks for clarifying that thread model selection is UI-driven in Codex Desktop.
The blocker is: when using API-key auth via config.toml, the model picker UI is not shown, so users have no way to choose or change the thread model in the app.
In that mode, Desktop still starts threads with model
gpt-5.3-codex(from thread state), which can be unauthorized for the key and causes 401. With the same config, Codex CLI correctly usesgpt-5.4.So this is effectively a UX/behavior gap:
1) UI controls define thread model, but
2) UI controls are unavailable in API-key mode.
Could you either:
config.tomlmodel when model picker is unavailable,When you say that the model picker UI isn't shown, are you sure about that? What do you see in the UI in that case? Can you paste a screen shot of that part of the UI? If the model picker is missing, that sounds like a bug.
@etraut-openai Yes, I’m sure. The model picker is missing for me in API-key auth mode.
I did include a screenshot in the issue body, and I’m attaching a zoomed-in screenshot again here for clarity.
Please take a careful look at the screenshot and tell me exactly where the model can be selected in this UI. I cannot find any model picker anywhere.
<img width="2018" height="1382" alt="Image" src="https://github.com/user-attachments/assets/41daaafb-2a45-4939-8585-6f1f08488716" />
@etraut-openai As mentioned in the issue body. This is effectively a UX/behavior gap: UI controls define thread model, but UI controls are unavailable in API-key mode. As for whether this is a UI bug, you can test it yourself—I’ve included the reproduction steps.
Ah, I just realized that you're using Azure. I think that's the key here. Reopening and changing the title.
I know what's going on. You're using a custom model provider because you're using an Azure endpoint. We're tracking that issue in #10867.