Model selection in desktop app reverts to gpt-5.3-codex — server-side Statsig config overrides user choice
What version of the Codex App are you using (From “About Codex” dialog)?
0.112.0
What subscription do you have?
Pro
What platform is your computer?
Darwin 25.2.0 arm64 arm
What issue are you seeing?
Summary
On the Codex desktop app (macOS, v0.112.0, Pro plan), model selection reverts to gpt-5.3-codex immediately after choosing any other model. The picker renders all 12 models but the selection never persists. The CLI/TUI works correctly — this is app-only.
Actual behavior
Selection always reverts to gpt-5.3-codex. I had working access to gpt-5.4 for ~3 days before this started.
What I found
A Statsig dynamic config (ID: 107580212) is pushed server-side into the Electron app's Local Storage. The config contains:
{
"available_modele": [],
"default_model": "gpt-5.3-codex",
"use_hidden_models": false
}
- Rule ID: 7trR3I8WKjmHUC9cbPaof:100.00:3-7trR236us9Sov4dB3Tx5d — 100% rollout for group 3, scoped by userID
- The field available_modele appears to be a typo (modele vs models). Since the desktop app is closed-source (unlike the CLI), it's unclear whether the app reads this field or
if the model lock is happening through a different mechanism.
- The local models_cache.json correctly lists 12 models including gpt-5.4 with visibility: "list" and priority: 0 — the cache is fine.
What doesn't fix it
- Deleting ~/.codex/models_cache.json (re-fetched on launch)
- Clearing Electron caches (~/Library/Application Support/Codex/)
- Reinstalling the app (same account = same Statsig group)
- Signing out and back in
Why the CLI is unaffected
The CLI reads from config.toml and doesn't use Statsig dynamic configs. The open-source CLI codebase has zero references to available_modele.
Environment
- App version: 0.112.0
- Platform: macOS (Darwin)
- Plan: Pro
- Previously working: gpt-5.4 was selectable and functional for ~3 days before this regression
What steps can reproduce the bug?
- Open Codex desktop app (macOS, v0.112.0)
- Open the model selector
- Select any model other than gpt-5.3-codex (e.g., gpt-5.4)
- Selection reverts to gpt-5.3-codex within ~1 second
What is the expected behavior?
Selected model persists and is used for completions, like the CLI's /model command.
Additional information
_No response_
10 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Which version of the app are you using? The version number you provided is a CLI version number. You can find the app version in the "Codex -> About Codex" dialog.
Was this working correctly for in the previous release of the app? I'm trying to determine if this is a regression. That will help us assess the priority.
Hey @etraut-openai, my bad!
Using: Version 26.305.950 (863)
Yes, it has always been working until a few days ago. I was switching between gpt-5.4 and 5.3-codex just a few days ago.
@etraut-openai FYI, I've updated to new versions of Codex and I still have the issue. I can't seem to access GPT-5.4 even though I have a Pro subscription.
This may be a Statsig issue where my account is being blocked for some reason.
I'm currently on version: 26.311.21342
@JayThibs, please use
/feedbackto upload your logs and post the thread ID.Here it is @etraut-openai
019ce76f-b97b-7ca2-ac9e-032d7fa55073
@JayThibs, thanks for uploading. I looked up your account. On first inspection, I don't see any obvious reason why you shouldn't have access to gpt-5.4.
Here are a few things to try:
~/.codex/models_cache.jsonand relaunch the app.@etraut-openai I just did all of the above; unfortunately, it did not work.
However, I found the issue! Turns out 5.3-codex and xhigh were hardcoded in .codex/config.toml in this particular codebase because I was using codex via CLI. It was a project-level config, not Statsig. This project-level config was overriding the desktop app's model picker.
I originally set this up for CLI usage (codex --print) where hardcoding a default model made sense. I didn't realize the desktop app also reads the project-level .codex/config.toml and treats it as authoritative, silently overriding whatever you select in the UI picker.
I realized what the issue might be once I tried it in another repo and didn't get the issue.
What made it confusing:
The fix: Removed the model and model_reasoning_effort lines from the project's .codex/config.toml, keeping only non-model settings (approval policy, sandbox, profiles, etc.).
Potential suggestion for the team: When a project-level config locks the model, the picker UI should either (a) show that the model is pinned by project config, or (b) let the user override it from the picker.
Glad to hear you figured it out — and that it wasn't a regression after all.
I'm going to close this bug report. You're welcome to file a separate feature request with your suggested improvements.
I had a similar problem and in my case it was because I had an incorrect config. I have two computers, one for work and one private. I share the config between them and this config-section was confusing my work-setup since I didnt have that file. Then I couldnt use the app at all, not switching models and not starting chats.
[agents.researcher]
description = "Background read-only researcher for web/docs fact-finding and concise evidence summaries."
config_file = "agents/researcher.toml"