Desktop app: context overflow can terminate a turn before any compaction runs, then reset status to '100% left (0 used / 760K)' and finish with no agent message
What version of Codex is running?
Codex Desktop / app-backed session cli_version: 0.108.0-alpha.12
What subscription do you have?
Pro
Which model were you using?
gpt-5.4
What platform is your computer?
macOS (Desktop app-backed session)
What issue are you seeing?
I hit:
Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying.
But this does not appear to be the same failure mode as the existing remote compaction failures.
In my case, the turn appears to overflow before compaction runs at all:
- the local session JSONL contains zero
type:"compaction"events - immediately after the failure, the UI/status showed:
100% left0 used / 760K- the turn then ended with
task_completeandlast_agent_message: null
So from the user side it looks like Codex both:
- says it ran out of context, and
- simultaneously says there is effectively a fresh / empty context window.
That combination is misleading and makes this look different from:
- remote compaction failing with
context_length_exceeded - compaction loops
- post-compaction percentage display bugs
Why I think this is a distinct issue
Related issues I found:
- #8190
- #12468
- #13271
- #9800
- #11440
- #9417
Those are close, but this report is specifically about:
- no compaction attempt being recorded at all
- a silent task termination
- a reset/misleading status readout after failure (
100% left,0 used / 760K) - likely a single oversized in-flight turn/tool payload that overflows before auto-compaction can trigger
What steps can reproduce the bug?
I do not have a minimal repro yet, but this happened in a fresh thread while the agent was doing web/doc lookups.
The pattern seems to be:
- Start a fresh thread in Codex Desktop
- Ask Codex to inspect/open multiple large docs/web pages and keep working in the same turn
- The turn eventually errors with the normal "ran out of room" message
- Instead of showing a compaction attempt/failure, the session:
- records no compaction events
- resets the visible status to
100% left (0 used / 760K) - ends with no last agent message
What is the expected behavior?
One of these should happen instead:
- auto-compaction should run before the turn is terminated, or
- Codex should surface a clear pre-compaction overflow error saying the current in-flight request was too large to compact, or
- the UI should not reset to
100% left / 0 usedimmediately after a context overflow if that is not actually the usable state
Additional information
Affected session ID:
019cc407-9cbf-7f40-9586-1c5f12f5a7bf
Local session inspection found:
compaction_events = 0- final token/status events showing
model_context_window = 760000 - then a reset-like status event with
0 used / 760K - then
task_completewithlast_agent_message = null
This looks like:
pre-compaction turn overflow + misleading post-failure context status + silent task completion
4 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
When will this be worked on. Codex-5.3 and codex-5.3-spark are completely useless and they keep churning tokens without editing any code until they "run out of room"
I have an additional related case from Windows/Codex Desktop. It is not an exact match to the original "zero compaction events" detail, because this rollout had earlier
context_compactedevents, but the tail failure has the same user-visible shape: turns complete successfully withlast_agent_message: nulland no assistant output.Environment from local
session_meta/turn_context:Relevant tail sequence:
Other local checks:
Notes:
last_agent_message: null; that might be expected for quiet heartbeats.task_completeand no assistant message, once before and once afterthread_rolled_back.This looks like either a related context-accounting failure or a session lifecycle/replay issue where the app/core marks the turn complete even though no assistant item was produced.
Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use
/feedbackand open a new bug report.