Codex Desktop 26.519.41501: remote compaction fails with context_length_exceeded across multiple threads

Resolved 💬 3 comments Opened May 23, 2026 by zgl-gits Closed May 23, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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?

  1. Use Codex Desktop 26.519.41501 on Windows with gpt-5.5.
  2. Resume or continue several existing long-running Codex Desktop threads.
  3. Let automatic context compaction trigger.
  4. Observe that remote compaction fails with context_length_exceeded.
  5. 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.

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.

  • #24089
  • #24014
  • #23589
  • #24002
  • #24078

Powered by Codex Action

selaquik · 3 months ago

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.

zgl-gits · 3 months ago

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_image entries / data:image or base64 strings / oversized tool outputs, and those records were still being included when the thread resumed or compacted.

What worked locally:

  1. Locate the affected session JSONL under the local .codex/sessions directory.
  2. Make a full backup before changing anything.
  3. Stream-parse the JSONL and replace historical input_image objects plus inline image/base64 payload strings with short text placeholders.
  4. Preserve normal text messages, timestamps, event order, and JSONL structure.
  5. Validate the repaired candidate: JSON parse errors must be 0, no remaining image_url / input_image entries, and no oversized image/base64 rows.
  6. Replace the original session only after verifying the source file still matches the backup hash.
  7. Verify with a lightweight codex exec resume --ephemeral ... "Reply OK only" run.

This recovered two affected Desktop threads for me:

  • One session went from about 52.65 MB to 10.33 MB and resumed successfully.
  • Another went from about 39.44 MB to 19.69 MB and also resumed successfully.

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 compacted records, excluding prior heavy compact/image/tool payloads from future compact input, and providing an official prune/repair session command.