codex - 💡(How to fix) Fix Codex app /compact fails with context_length_exceeded after UI says “Context compacted” [1 comments, 2 participants]

What version of the Codex App are you using (From “About Codex” dialog)?

26.513.31313 (2867)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

Product / component: Codex desktop/app, thread compaction, /compact, remote /responses/compact task

Model: GPT-5.5 Extra High

Severity: High. Long-running Codex thread becomes unable to compact, risking loss of working context and making it difficult to continue work.

Summary: When running /compact in a long Codex thread, the UI first reports “Context compacted”, but then the remote compact task fails with context_length_exceeded. No successful new compact record appears to be written after the failure.

Actual behavior: The app shows:

Context compacted

Then reports:

Error running remote compact task: { "error": { "message": "Your input exceeds the context window of this model. Please adjust your input and try again.", "type": "invalid_request_error", "param": "input", "code": "context_length_exceeded" } }

Local evidence: The local session JSONL still exists and appears intact.

Observed local metrics around the failed compaction:

estimated_tokens_of_items_added_since_last_successful_api_response=245649 estimated_bytes_of_items_added_since_last_successful_api_response=982594 model_context_window_tokens=258400 failing_compaction_request_model_visible_bytes=1424086 compact_error=context_length_exceeded

There was also a very large recent user message of roughly 601,418 characters, which appears duplicated in the event log. The compaction payload appears to be near the model context window before adding compactor/system overhead, then exceeds the limit once the remote compact request is assembled.

Expected behavior: Codex /compact should not send a compaction request that exceeds the target model’s context window after overhead is added.

Expected alternatives:

• Chunk or recursively compact oversized histories.
• Prune or summarize very large recent event payloads before sending to /responses/compact.
• Trigger compaction earlier before the thread reaches an unrecoverable size.
• Fail before showing “Context compacted” if the remote compact task did not actually complete.
• Provide a recovery path for oversized threads, such as “compact last N turns”, “compact excluding tool/event duplicates”, or “create handoff summary from local session.”

Impact: The user cannot compact or continue a high-context Codex thread normally. The thread contains important work context, and the failure mode is confusing because the UI initially says compaction succeeded.

What steps can reproduce the bug?

• Session ID: 019e2c54-f2a2-79b2-ab82-cfa092dca614
• Compact turn ID: 019e42d3-7176-7990-bbbd-6e6d277be883
• Request ID: 5dcf980d-43ee-4bc6-98ab-b140ff6585f8

What is the expected behavior?

Codex /compact should not send a compaction request that exceeds the target model’s context window after overhead is added.

Additional information

This was initially noticed around the May 20th OpenAI API incident affecting GPT-5.4/GPT-5.5 https://status.openai.com/incidents/01KS19AHSEE3DAX1HHKNQB166F , but subsequent checks showed the status page had returned to operational. The later failure appears deterministic and tied to context length rather than a transient outage.