GPT-5.5 Codex session hits unrecoverable compaction failure around ~220k tokens despite advertised 400k context

[rstqxq]

What version of Codex CLI is running?

0.124.0

What subscription do you have?

GPT-5.5 is marketed as a Codex model with 400K context and tuned long-running behavior, but it appears not to support /responses/compact/native compaction. As a result, every GPT-5.5 Codex session is effectively non-recoverable once it approaches the context limit. This makes GPT-5.5 unusable for long-running Codex work despite being positioned as the recommended Codex model.

Which model were you using?

gpt-5.5

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

No response

What issue are you seeing?

GPT-5.5 is marketed as a Codex model with 400K context and tuned long-running behavior,
but it appears not to support /responses/compact/native compaction.
As a result, every GPT-5.5 Codex session is effectively non-recoverable once it approaches 272k tokens context.
This makes GPT-5.5 unusable for long-running Codex work despite being positioned as the recommended Codex model.

What steps can reproduce the bug?

Environment

• Codex CLI version: <paste codex --version here>
• OS: <Windows / macOS / Linux>
• Auth mode: ChatGPT login / Codex subscription
• Plan: Pro
• Model: gpt-5.5
• Also reproducible when gpt-5.5 is used as a subagent from a gpt-5.4 parent session.

Config

model = "gpt-5.5"
model_reasoning_effort = "xhigh"

# I tried both the default settings and explicit lower limits.
# The failure still happens once the session gets close to the effective context limit.
model_auto_compact_token_limit = 180000
tool_output_token_limit = 8000

Reproduction steps

Start a fresh Codex session using gpt-5.5 xhigh.
Work on a non-trivial repository task that causes the session context to grow.
For example:
- ask Codex to inspect multiple source and test files;
- run test/build commands with tool output;
- continue several implementation/debugging turns until the session reaches roughly 200k–220k tokens.
- Wait for Codex to trigger remote compaction automatically, or continue the task until compaction is required.
- The remote compaction task fails.
After the first failure, continuing the same session usually keeps failing because the same oversized conversation history is reused. The session effectively becomes unrecoverable.
error belike：
Error running remote compact task:
{"error":{"message":"invalid_request_error: 请求格式非法，请检查请求结构是否符合 API 规范", "type":"invalid_request_error", "code":"invalid_request_error"}}
or
Error running remote compact task:
unexpected status 503 Service Unavailable:
所有供应商暂时不可用
url: /v1/responses/compact

### What is the expected behavior?

_No response_

### Additional information

_No response_

[github-actions]

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

• Auto compact error #19255
• Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying #19269
• TUI runs out of context with gpt-5.5 despite auto-compact config #19183
• GPT-5.5 reports 258400 context window in Codex despite published 400K window #19319

Powered by Codex Action

[rstqxq]

This may be related to #19306 / #19319, but I think this report captures the downstream failure mode rather than only the displayed context-window mismatch.

The issue is not just that GPT-5.5 reports ~258400 instead of the advertised 400K context window.

The practical failure is:

• GPT-5.5 Codex sessions become unsafe around ~200k–220k tokens.
• Remote/native compaction fails when the session reaches that zone.
• After the first compaction failure, the same session tends to be unrecoverable because retrying reuses the same oversized history.
• The same behavior can happen in GPT-5.5 subagents.
• This makes GPT-5.5 effectively unusable for long-running Codex work unless it is treated as a short-lived one-shot subagent.

This appears consistent with #19255, which reports auto compact errors near the effective context limit with model_context_window_tokens=Some(258400) and subagent failures.

So even if the root cause overlaps with #19306 / #19319, the user-visible bug here is the unrecoverable compaction failure, not only the context-window display value.

[GGBondBlueWhale]

Same here

[nilswx]

Same here, something isn't right. I now try to drastically scope my sessions with subagents and handing off work to (parallel) sessions via app-server, but it's a far cry from the advertised 400K or "Codex automatically compacts its context".

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact) is (still) a real productivity killer.

A weak workaround to get past a compaction hump is switching from gpt-5.5 to gpt-5.3-codex or even gpt-5.4-mini (and then back to gpt-5.5), but this really hurts session performance and likely also thrashes context caches + quota consumption.

[asaffoox]

I am seeing a closely related issue on Codex CLI under Windows 11 + WSL2.

My GPT-5.5 Codex session reported:

Current context:
- 187,339 / 258,400 tokens
- 72.50% used
- Warning: above 70%

Earlier in the same session, Codex explicitly changed its behavior because the context was above 70%:

The edit is now done locally through Word COM and recorded. Context is now above 70%, so I’m keeping the audit subagent prompt very tight. It will be read-only, open the edited DOCX through Word COM, verify the required text/table markers, and write its handoff.

Environment:

• Codex CLI version: 0.125.0
• npm package: @openai/codex@0.125.0
• Auth: ChatGPT login
• Model: gpt-5.5
• Platform: Windows 11 + WSL2
• WSL version: 2.6.3.0
• Ubuntu: 24.04.4 LTS
• Windows build: 10.0.26200.8246
• Node: v24.14.0
• npm: 11.9.0

For large-codebase work, this makes the usable session much smaller than expected. Once the session is above 70%, Codex starts behaving as if it must conserve context, so the practical working limit is around 180K tokens, not 400K.

The issue is not only the displayed number. The practical problem is that long-running GPT-5.5 Codex work becomes fragile too early. This directly affects whether GPT-5.5 Codex can be used seriously for large software projects.