Codex Desktop local threads ignore ~/.codex/config.toml and stay at model_context_window=258400

Summary

Codex Desktop local GUI threads appear to ignore ~/.codex/config.toml for context window settings.

On the same macOS machine:

• ~/.codex/config.toml has profile = "auto_precision"
• that profile sets model_context_window = 1050000
• terminal codex exec can successfully process single-turn prompts with 394k to 402k input tokens
• but Codex Desktop GUI threads still report model_context_window = 258400

This looks specific to the Desktop GUI thread-start path, not to the model itself and not to the embedded codex binary.

Environment

• macOS
• Codex Desktop app version: 26.305.950
• Desktop build: 863
• Embedded CLI in Desktop: codex-cli 0.108.0-alpha.12
• Standalone CLI on same machine: codex-cli 0.111.0
• model used in repro: gpt-5.4

Repro

1. Set the default profile in ~/.codex/config.toml to:

• profile = "auto_precision"
• model_context_window = 1050000

1. Open Codex Desktop and start a local GUI thread using gpt-5.4.
2. Hover the context indicator in the UI.
3. Observe that the UI still shows ... / 258k tokens used.
4. Inspect the rollout JSONL for that Desktop session.
5. Observe that task_started and subsequent token usage events still report model_context_window = 258400.
6. On the same machine, run either:

• standalone codex exec
• or /Applications/Codex.app/Contents/Resources/codex exec

1. Feed a large single-turn prompt.
2. Observe that CLI runs succeed with 394k to 402k input tokens.

Expected

Desktop GUI local threads should honor the effective config/profile from ~/.codex/config.toml, or at minimum the UI should reflect the actual effective context window.

Actual

Desktop GUI local threads stay at model_context_window = 258400, while terminal CLI paths on the same machine successfully handle much larger single-turn inputs.

Evidence

• Desktop rollout JSONL shows model_context_window = 258400 in task_started and token usage updates.
• standalone CLI run completed with input_tokens = 394027
• Desktop-bundled CLI run completed with input_tokens = 402401
• Check for Updates… in Desktop reports that 26.305.950 is already the newest available version, so this is reproducible on the latest publicly available Desktop build on this machine.

Possible cause

After inspecting the installed Desktop bundle locally, it appears the GUI thread creation flow fetches config through mcp-codex-config, but the Electron-side handler currently returns config: null. If that is the code path actually used for local GUI threads, it would explain why the GUI path does not inherit the config/profile that the CLI path does.

I realize the last part is based on local bundle inspection rather than an official API contract, so the main bug report here is the externally observable mismatch:

• same machine
• same config
• same model family
• CLI honors large context
• Desktop GUI remains at 258400