[App] Allow the model picker to override project-scoped model defaults

[ruslander-rulez]

What variant of Codex are you using?

Codex App (macOS desktop)

What feature would you like to see?

Treat model and model_reasoning_effort in a trusted project's .codex/config.toml as defaults for new tasks, while allowing an explicit selection in the composer model picker to override those defaults for the current task or thread.

Current behavior

When a project-scoped .codex/config.toml contains a model default, selecting another available model in the desktop app briefly updates the picker, but the selection immediately snaps back to the project-configured model. The picker appears interactive even though its selection cannot take effect.

Requested behavior

• Use the project-scoped model and model_reasoning_effort values when the user does not make an explicit selection.
• Treat an explicit composer selection as a task/thread-level override.
• Do not rewrite the project configuration when applying the temporary override.
• When a project setting is intentionally authoritative and cannot be overridden, disable the affected picker control and show that the value comes from .codex/config.toml.

This would preserve reproducible project defaults while still allowing users to choose a faster, cheaper, or more capable model for a specific task.

Additional information

Reproduction

1. Open a trusted local project in the Codex desktop app.
2. Add a project-scoped configuration:

model = "gpt-5.6-sol"
model_reasoning_effort = "medium"

3. Open the model picker below the composer.
4. Select another available model or reasoning level.
5. Observe that the picker briefly changes and then returns to the project-configured value.

Expected result

The explicit picker selection remains active for the current task/thread. The project configuration remains unchanged and continues to provide the default for tasks where no explicit selection is made.

Environment

• ChatGPT desktop app: 26.721.81911 (build 5973)
• Bundled codex-cli: 0.146.0-alpha.3.1
• macOS: 26.5.1 (25F80)

Related issues

• Model selection in desktop app reverts to gpt-5.3-codex — server-side Statsig config overrides user choice #14008 — same root cause; closed with a suggestion to file a separate feature request for the UX improvement
• Model selection immediately reverts to default model after choosing a different one #10875 — model selection immediately reverts to the default model
• [App] Reasoning-effort picker cannot override project .codex/config.toml default #34535 — analogous open issue for model_reasoning_effort

Removing model and model_reasoning_effort from the project-scoped config allows the picker to work, but removes the ability to define project defaults.

[fenicottero-loriot]

Windows/WSL confirmation with an additional configuration-path collision and timing evidence.

Environment:

• Windows Codex/ChatGPT Desktop MSIX: OpenAI.Codex_26.803.10989.0_x64__2p2nqsd0c76g0
• Bundled/About build observed: 26.803.81509
• WSL2 Ubuntu
• Legacy WSL agent environment enabled
• Project root: /home/<wsl-user>

The project-root choice is significant: for this project, the WSL user config

/home/<wsl-user>/.codex/config.toml

is also located at the exact path the project sees as:

<project-root>/.codex/config.toml

It contains:

model = "gpt-5.6-sol"
model_reasoning_effort = "medium"

The Windows Desktop config is a separate file under C:\Users\<user>\.codex\config.toml.

Observed behavior:

1. Open/create a task in the /home/<user> project.
2. Use the composer model picker to select another available model or effort, for example gpt-5.6-sol / high.
3. The picker sometimes remains on the explicit selection, but often snaps back to sol / medium after roughly 60-100 ms.
4. The same problem previously occurred with a gpt-5.5 / medium default, so this is not specific to GPT-5.6 or to model entitlement.

Desktop logging and a read-only config monitor show that the click is not being rejected:

Setting default model and reasoning effort
newModel=gpt-5.6-sol newEffort=high

config/batchWrite -> success
config/read (primary renderer) -> success, ~40-90 ms
config/read (second renderer)  -> success, ~40-90 ms

Three repeated sol/high selections all completed config/batchWrite successfully. During a later controlled sequence, the Windows config successfully changed through:

gpt-5.6-terra / medium
gpt-5.6-luna  / medium
gpt-5.5       / medium
gpt-5.6-sol   / high

while the WSL config remained gpt-5.6-sol / medium throughout. At one point the UI had already snapped back to medium even though the Windows config still persisted sol/high.

This strongly suggests a state-precedence/reconciliation race rather than model unavailability:

• the picker action writes a default model through config/batchWrite;
• the active/project configuration is re-read by two renderer contexts immediately afterward;
• the project/WSL medium snapshot can overwrite the composer's explicit selection;
• depending on timing, the explicit selection sometimes survives, which explains the intermittent reproduction.

The official current config reference says explicit model/reasoning choices for a new thread should override defaults, and project config should behave as a configuration layer rather than making an apparently enabled picker ineffective.

Suggested regression case:

1. Set the project root to the user's home directory so ~/.codex/config.toml and <project>/.codex/config.toml resolve to the same path.
2. Use distinct Windows Desktop and WSL Codex config homes.
3. Put model_reasoning_effort = "medium" in the WSL/home config.
4. Select high in the new-task composer.
5. Verify the selection becomes a task/thread override and is not replaced by either renderer's asynchronous config read.
6. Verify the picker operation does not rewrite unrelated global defaults.

A temporary workaround is to remove model and model_reasoning_effort from the project-visible config, but that also removes the desired WSL/user default and does not solve the product-level precedence problem.

[vojinpu]

Windows-native confirmation (no WSL) on the current Codex desktop build.

Environment

• Codex MSIX: 26.818.8289.0
• Desktop runtime: codex-cli 0.149.0-alpha.4.3
• Windows 11 Pro 25H2, build 26200.9168, x64

Configuration and observed behavior

User config sets the intended default:

model = "gpt-5.6-sol"
model_reasoning_effort = "xhigh"
plan_mode_reasoning_effort = "xhigh"

A trusted project config had this higher-precedence override:

model_reasoning_effort = "ultra"
plan_mode_reasoning_effort = "xhigh"

With that project open, selecting another available model in the composer immediately snapped back to GPT-5.6 Sol / Ultra. This reproduced with multiple alternatives rather than one unavailable model.

The desktop log recorded the picker/default write as newModel=gpt-5.6-sol newEffort=xhigh, while the active task metadata resolved to model=gpt-5.6-sol effort=ultra from the project layer. The UI gave no indication that a project config layer had overridden the explicit selection.

Expected behavior: Sol / Extra High can initialize the composer as the default, but an explicit model selection should persist for that task. If project-scoped values are intentionally authoritative, the picker should be disabled or identify the forcing config layer instead of briefly accepting the click and silently reverting.

Local workaround: change or remove the project-level model_reasoning_effort override so it no longer conflicts with the intended global default.