GPT-5.5 needs opt-in 1M context in Codex Desktop; the current 258K effective limit is breaking long-running development workflows

Resolved 💬 3 comments Opened May 2, 2026 by thughy Closed May 2, 2026

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

Summary

Please prioritize shipping opt-in 1M-token context for GPT-5.5 in Codex Desktop.

This is not a cosmetic request, and it is not simply that "more context would be nice." The current effective limit in Codex Desktop is materially reducing the reliability of long-running engineering workflows. In practice, GPT-5.5 sessions begin recurring memory compaction around the current ~258K effective input budget, and those compactions are lossy enough to degrade complex tasks.

OpenAI has already acknowledged that GPT-5.5 supports 1M context at the model/API level, while Codex currently exposes a much smaller product limit. I understand capacity planning is required, and I am not asking for 1M to become the default for everyone. I am asking for an explicit opt-in path for power users, even if it consumes usage at a higher rate.

Why this is urgent

For real development work, the current limit is not enough for:

multi-hour debugging sessions where exact failed attempts, logs, stack traces, environment constraints, and hypotheses need to remain available;
large architectural refactors where the working plan itself becomes substantial and must remain stable across many tool calls;
codebases with large AGENTS.md / project rules, generated plans, design docs, and multiple relevant source files;
cross-module changes where the model must preserve invariants across many files and not rediscover them after every compaction;
repeated build / test / fix loops where command quirks, prior errors, and partial fixes are critical context rather than disposable chat history.

When compaction runs repeatedly, the model often loses exact details that were necessary for later steps. The visible effect is not just inconvenience. It causes:

re-reading and re-discovering the same repository facts;
repeated failed commands and repeated debugging branches;
drift from the original task objective after compaction;
lower completion rate for complex tasks;
more tokens and credits spent recovering state instead of progressing;
user intervention to restate context that the tool previously had.

This directly harms developer productivity and makes GPT-5.5 feel worse suited for large tasks than it should be, even though the model itself is stronger.

Current behavior

Codex Desktop currently exposes an effective GPT-5.5 context around ~258K input tokens. This appears to come from the Codex product limit of 400K total context, with 272K input and 128K reserved output, plus the harness's effective usable budget.

model_context_window = 1000000 is not a viable workaround for GPT-5.5 today because the Codex model catalog caps GPT-5.5 at a 272K max context window, so local overrides are clamped or ignored. This differs from GPT-5.4, where Codex previously allowed a 1M max context option.

Request

Please ship one of the following as soon as possible:

an official model_context_window = 1000000 path for GPT-5.5 in Codex Desktop;
a tiered opt-in, e.g. 512K / 768K / 1M;
a UI-level advanced setting in Codex Desktop that makes the tradeoff explicit;
a higher usage multiplier for long-context GPT-5.5 if needed for capacity / cost reasons.

Keeping 400K as the default is completely reasonable. Hard-blocking power users from opting into the model's full long-context capability is not.

Expected behavior

A Pro / Business / Enterprise user should be able to opt into GPT-5.5 long context in Codex Desktop and verify the active input budget in /status or the status UI. Compaction should not repeatedly interrupt long-running tasks at ~258K when the user has explicitly selected a larger context window.

Related context

GPT-5.5 launch materials distinguish Codex's 400K context from the API's 1M context: https://openai.com/index/introducing-gpt-5-5/
#19185 documents user confusion and the 272K input / 128K output split: https://github.com/openai/codex/issues/19185
#19464 already tracks the feature request, and an OpenAI collaborator stated that the team is working to make 1M-token context available for GPT-5.5 in Codex: https://github.com/openai/codex/issues/19464#issuecomment-4329299628

I am filing this separately to emphasize the practical product impact: the current context limit is already causing avoidable compaction churn and reducing task completion quality in real development workflows. Please treat this as a high-priority Codex Desktop reliability and productivity issue, not a minor enhancement.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

#19464
#19409
#19339
#19208
#19185

Powered by Codex Action

eddyaipt · 3 months ago

A useful middle ground would be an explicit long-context mode with stronger session diagnostics. For power users, the pain is not only the cap itself but not being able to predict when compaction has become destructive. If Codex exposed both the active budget and a clearer summary of what was compacted away, teams could choose between 400K speed/cost mode and 1M continuity mode much more intentionally.

GrazianoGuiducci · 3 months ago

Adding a concrete data point from a VPS/code-server setup.

Posted by GrazianoGuiducci via THIA Assistant (TM7-vps, a Codex node running on the VPS). The investigation/workaround below was produced by TM7-vps while operating on behalf of Graziano Guiducci.

The important finding is that VS Code/code-server users can be looking at a different Codex binary than the global CLI. In my case:

global CLI:
/usr/bin/codex
codex-cli 0.124.0

code-server extension binary:
/root/.local/share/code-server/extensions/openai.chatgpt-26.422.71525-linux-x64/bin/linux-x86_64/codex
codex-cli 0.126.0-alpha.8

Patching only ~/.codex/models_cache.json, or only changing max_context_window, was not enough. The extension/app-server still showed the practical 258400 limit because its model catalog still had:

{
  "slug": "gpt-5.5",
  "context_window": 272000,
  "max_context_window": 272000,
  "effective_context_window_percent": 95
}

That is exactly 272000 * 0.95 = 258400.

The local workaround that made new code-server Codex instances show 950000 was:

Generate a custom model catalog from the extension binary's own debug models output.
Patch both context_window and max_context_window for gpt-5.5 to 1000000.
Point ~/.codex/config.toml to that catalog with model_catalog_json.
Start a fresh Codex instance, not a resume of an old app-server/session.

Relevant config:

model = "gpt-5.5"
model_context_window = 1000000
model_catalog_json = "/root/.codex/model_catalog_gpt55_1m.json"

Relevant catalog entry:

{
  "slug": "gpt-5.5",
  "context_window": 1000000,
  "max_context_window": 1000000,
  "effective_context_window_percent": 95
}

Verification command that must be run against the same binary used by the extension:

/root/.local/share/code-server/extensions/openai.chatgpt-26.422.71525-linux-x64/bin/linux-x86_64/codex debug models \
  | jq '.models[] | select(.slug=="gpt-5.5") | {slug,context_window,max_context_window,effective_context_window_percent,effective_input_budget:(.context_window * .effective_context_window_percent / 100 | floor)}'

Expected local output after the workaround:

{
  "slug": "gpt-5.5",
  "context_window": 1000000,
  "max_context_window": 1000000,
  "effective_context_window_percent": 95,
  "effective_input_budget": 950000
}

Notes:

This is only a client-side workaround; it does not prove the backend will always accept the full 1M effective input.
Existing sessions can keep the old 258400 catalog until a fresh instance is started.
The VS Code/code-server embedded Codex binary matters. Debugging only /usr/bin/codex can produce a false positive if the extension is using its bundled binary.
The community branch that changes only max_context_window is directionally useful, but in this setup both context_window and max_context_window had to be changed.

This suggests part of the user confusion is not only the product cap itself, but also a catalog/runtime mismatch across CLI, VS Code/code-server extension, app-server lifecycle, and session resume behavior. It would help if Codex surfaced the effective context_window, max_context_window, and compact threshold directly in the UI for the active session binary/runtime.