Codex Desktop 26.519.41501: remote compaction fails with context_length_exceeded across multiple threads
What version of the Codex App are you using (From “About Codex” dialog)?
Observed from Codex Desktop logs: 26.519.41501.
What subscription do you have?
Not included in this public report.
Which model were you using?
gpt-5.5 with high/extra-high reasoning in the Codex Desktop app.
What platform is your computer?
Microsoft Windows 11, version 10.0.26200, x64.
What issue are you seeing?
Multiple Codex Desktop threads started failing automatic context compaction with the same remote compact error:
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" } }
This appears to be generated by Codex's automatic remote compaction path rather than by a new oversized user prompt. It affects multiple existing threads, including long-running project threads that previously compacted successfully.
Local log evidence, with private paths and conversation content omitted:
codex_core::compact_remote
responses/compact
context_length_exceeded
model=gpt-5.5
model_context_window_tokens=Some(258400)
all_history_items_model_visible_bytes roughly 3.06 MB to 9.22 MB on affected threads
last_api_response_total_tokens observed as high as 2305504 in one affected thread
features list shows request compression enabled locally:
enable_request_compression stable true
remote_compaction_v2 under development false
There were also concurrent signs of feature/UI mismatch in the same Codex Desktop session: the UI exposed the thread goal/target control, but calls such as thread/goal/get and thread/goal/set failed with:
goals feature is disabled
That may be unrelated, but it appeared around the same time as the compaction failures and may indicate a feature flag or desktop/app-server state mismatch.
What steps can reproduce the bug?
- Use Codex Desktop
26.519.41501on Windows withgpt-5.5. - Resume or continue several existing long-running Codex Desktop threads.
- Let automatic context compaction trigger.
- Observe that remote compaction fails with
context_length_exceeded. - Repeat in another long-running thread; the same failure appears again.
In this environment, the failures were observed across multiple threads around 2026-05-23, not just a single session.
What is the expected behavior?
Automatic remote compaction should not construct a /responses/compact request that exceeds the target model's context window.
If the thread is too large to compact in one request, Codex should chunk, trim, recursively summarize, or offer a recovery/handoff workflow instead of leaving the thread unable to continue.
What is the actual behavior?
The app attempts remote compaction, but the compaction task itself exceeds the model context window and fails with context_length_exceeded. Long-running threads become difficult or impossible to continue normally.
Additional information
CLI version observed locally:
codex-cli 0.133.0-alpha.1
Related reports that appear similar:
- #24089
- #24014
- #24078
- #24002
- #23589
This report is specifically from Codex Desktop on Windows with app log release 26.519.41501, and the notable symptom is that several existing threads failed remote compaction in the same time period.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
There are already many threads about this, but there’s still no solution. In practice, it completely broke the agent. I honestly don’t know if it’s even worth renewing the subscription anymore, because the only reason I bought it was for the agent. And now it breaks after just 2-3 messages.
Workaround confirmed: affected local sessions recovered
Update: I was able to recover the affected local Codex Desktop threads with a local session-slimming repair.
First, thanks to @huzp611 for the investigation in https://github.com/openai/codex/issues/24191#issuecomment-4525453287. That analysis pointed us in the right direction: the failure was not just a transient remote compact error. Some local session JSONL histories had accumulated model-visible heavyweight records, especially historical image payloads /
input_imageentries /data:imageor base64 strings / oversized tool outputs, and those records were still being included when the thread resumed or compacted.What worked locally:
.codex/sessionsdirectory.input_imageobjects plus inline image/base64 payload strings with short text placeholders.image_url/input_imageentries, and no oversized image/base64 rows.codex exec resume --ephemeral ... "Reply OK only"run.This recovered two affected Desktop threads for me:
I packaged the local workaround as a public Codex skill here:
https://github.com/zgl-gits/my-skill/tree/main/skills/codex-session-repair
The skill includes the repair workflow and scripts. By default it only creates a backed-up sanitized candidate; it only overwrites the original session when explicitly run with
-Apply.This is only a local workaround, of course. I still think Codex itself should guard against this class of failure by bounding
compactedrecords, excluding prior heavy compact/image/tool payloads from future compact input, and providing an officialprune/repair sessioncommand.