## 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

Potential duplicates detected. Please review them and close your issue if it is a duplicate. - #13738 - #13623 - #13025 - #13373 *Powered by [Codex Action](https://github.com/openai/codex-action)*

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

Open 💬 4 comments Opened Mar 9, 2026 by YouJianFengXue

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

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

profile = "auto_precision"
model_context_window = 1050000

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

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

Feed a large single-turn prompt.
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

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 5 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#13738
#13623
#13025
#13373

Powered by Codex Action

YouJianFengXue · 5 months ago

Additional technical detail from local Desktop bundle inspection on the same machine:

The problem does not appear to be a model-side or binary-side hard limit.

Using the Desktop-bundled binary directly from terminal (/Applications/Codex.app/Contents/Resources/codex exec) on the same machine, a single-turn run completed with input_tokens = 402401.
That makes it much less likely that 258400 is an actual hard cap for the embedded binary.

The Desktop GUI path appears to have a config bridge gap.

In the installed Desktop bundle (26.305.950, build 863), the Electron main-process handler for mcp-codex-config appears to return config: null.
In the GUI thread-start path, buildNewConversationParams(...) fetches that value and then passes config through to thread/start / thread/resume.
The parameter builder only merges returned config entries if that object is non-null, so if mcp-codex-config is null, local GUI threads would not inherit config values such as model_context_window from ~/.codex/config.toml.

The Desktop UI also appears to be showing upstream metadata rather than inventing 258400 locally.

The context tooltip is driven from latestTokenUsageInfo.modelContextWindow.
That value is updated from the thread/tokenUsage/updated event payload.
In the affected Desktop session rollout JSONL, task_started and token-usage events consistently report model_context_window = 258400.

So the externally visible behavior still looks like this:

same machine
same local config
same model family
CLI path honors large context
Desktop GUI local-thread path remains at 258400

The local bundle inspection suggests the mismatch may be caused by the GUI thread-start path not receiving the resolved Codex config/profile at all.

YouJianFengXue · 5 months ago

Quick clarification on the duplicate suggestions:

I agree this issue is likely related to some existing Desktop config-loading / config-honoring bugs, especially:

#13025 (Desktop ignores project-scoped .codex/config.toml MCP config)
#13373 (Desktop app does not honor network_access = true from config.toml)

But this issue appears narrower/different in scope:

it is about local GUI threads in Codex Desktop
with a user-level/global ~/.codex/config.toml
specifically for model_context_window / large-context behavior
where the CLI path on the same machine honors the large context, but the Desktop GUI thread path remains at model_context_window = 258400

So my current understanding is:

not a duplicate of the VS Code / TUI display issues
possibly related to the broader Desktop config bridge / config propagation problems in #13025 and #13373
but still worth keeping separate unless maintainers confirm it is the same underlying bug

Biblejustin · 4 months ago

Adding another concrete data point from a ChatGPT Pro user on macOS.

Environment:

Plan: ChatGPT Pro
Date observed: 2026-04-14
Codex Desktop local thread id: 019d89b3-b6cf-7fd3-8b9f-292f471fc457
Local session metadata shows: originator=Codex Desktop, cli_version=0.119.0-alpha.28, model_provider=openai
Local config at repro time: model = "gpt-5.4", model_reasoning_effort = "xhigh"

Observed behavior:

Session token usage event reports model_context_window = 258400
Right before auto-compaction failure, the same session reported last input_tokens = 236952 with cached_input_tokens = 234752
That then rolled into the separate compaction bug tracked in #17809

Important clarification:

I am not assuming Pro should automatically unlock a larger context window just because it is Pro
OpenAI's current Codex plan docs talk about higher usage/rate limits for Pro, not an explicit larger app context window: https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan
But OpenAI's GPT-5.4 model docs currently advertise a 1,050,000 token context window: https://developers.openai.com/api/docs/models/gpt-5.4

So the core question here is:

Is 258400 in Codex Desktop local threads an intentional product/runtime cap, or is it still a bug/config-path mismatch?

If intentional, it would help to document that Codex Desktop local threads do not expose the full raw model context window even when the underlying model supports more.