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

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.

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.