Codex Desktop 26.616: automatic context compaction fails at 258k/258k and aborts with context-window error
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop 26.616.51431
Released Jun 21, 2026
What subscription do you have?
ChatGPT Pro / Full access
What platform is your computer?
macOS, Apple Silicon / arm64
What issue are you seeing?
Hi Codex team,
A long-running Codex Desktop task just became unrecoverable even though the app had already entered automatic context compaction.
The UI showed:
Automatically compacting context- Context window:
100% full 258k / 258k tokens used- Model/mode:
5.5 Extra High - The task had been working for about
1m 10s
After that, Codex surfaced the error:
Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying.This looks like a context-compaction/recovery bug. If Codex detects the context is full and automatically starts compaction, that compaction path should still be able to complete. The user should not be forced to abandon the existing task/thread because the compaction operation itself cannot run inside the already-full context window.
What steps can reproduce the bug?
I do not have a minimal deterministic reproduction yet, but the observed flow was:
- Use Codex Desktop in a long-running thread/task.
- Continue until the UI reaches
258k / 258k tokens usedand shows100% full. - Codex enters
Automatically compacting context. - Instead of recovering/compacting, the thread fails with:
``text``
Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying.
What is the expected behavior?
When automatic compaction is triggered, Codex should provide a safe recovery path:
- compact before the active request reaches an unrecoverable state;
- or run compaction out-of-band against stored history rather than requiring the full thread to fit in the active model context;
- or preserve the thread/task state and allow retry after compaction.
The app should not ask the user to start a new thread after it has already detected the full context and attempted automatic compaction.
Additional information
Feedback uploaded successfully:
019ee8f8-10a3-7110-842f-ade6115b13d1Screenshots captured the feedback ID, the Automatically compacting context state, 258k / 258k tokens used, and the Codex version dialog.
Related/open issues may include context compaction failures such as #29302, #28920, and #29142, but this report is specifically for Codex Desktop automatic compaction reaching 258k / 258k and then failing instead of recovering the active task.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Compaction needs its own lifecycle outside the full context window.
Once the UI reaches the hard limit, record events such as: threshold crossed, snapshot id, compact attempt started, model/context budget used for compact, failure reason, and retry state. If compaction cannot run because the thread is already full, the app should still leave a resumable recovery record.
From the user's side, the important distinction is "task failed" versus "compaction failed but the thread can be recovered from snapshot X." Right now those collapse into the same dead-end error.
---
_Generated with ax._
Adding another datapoint from #30194 before closing it as duplicate.
The observed failure is not only that automatic compaction can fail at very high context. A related symptom is that compaction can appear to run, but the effective context usage does not meaningfully decrease afterward. From the user's point of view, the thread remains high-context / near-full, and the next turn still behaves as if compaction did not reclaim usable context.
Expected behavior: after automatic or manual compaction, Codex should show/enforce a materially lower effective context load. If it cannot reclaim enough space, it should say so explicitly and provide a recovery path, ideally including a fresh-context continuation on the same existing worktree/files/git state.