Codex Desktop auto-compaction completes but leaves long-running thread ~80% full, causing repeat compaction and usage waste
Summary
In a long-running, tool-heavy Codex Desktop agent thread, automatic context compaction reports success (Context automatically compacted) but the context meter immediately remains at roughly 80% full. This leaves only about 20% usable runway before another compaction cycle.
The result is a repeat loop:
compact -> resume nearly full -> run a few tool operations -> compact again
This is not merely a cosmetic meter problem. The affected thread repeatedly reprocesses state, loses working coherence, spends substantial paid usage, and becomes unreliable for production repository work.
Environment
- Product: Codex Desktop
- Platform: Windows 11
- Subscription: ChatGPT Pro
- Workload: long-running agentic repository coordination with many tool calls, GitHub operations, command outputs, and image evidence
- Observed: July 23, 2026
- A public elevated-error-rate incident was active at the time. This is included for correlation only; causality is not established.
Steps to reproduce
- Use a Codex Desktop thread for a long-running repository task with repeated tool calls and large tool outputs.
- Continue until automatic context compaction occurs.
- Observe the visible
Context automatically compactedevent. - Immediately inspect the thread's context-usage indicator.
- The thread remains approximately 80% full directly after compaction.
- Continue for a small number of operations; compaction triggers again.
Observed behavior
- Successful compaction reclaims only about 20% of the context window.
- Multiple compaction events occur close together.
- The active thread retains or rehydrates too much prior tool/output history.
- The agent repeats plans, loses acceptance criteria, and contradicts earlier state.
- Paid usage is consumed during repeated compaction/reprocessing without proportional task progress.
- The user can reach the usage limit while the production task remains incomplete.
Expected behavior
- A successful compaction should produce substantial working headroom, not resume near the next compaction threshold.
- Replacement history should be bounded, deduplicated, and exclude raw historical tool output that is no longer needed in the active prompt.
- If compaction cannot reclaim enough space, Codex should explicitly report compaction failure or recommend a bounded handoff to a new thread rather than silently continuing near capacity.
- Context telemetry should distinguish original history, compacted summary, retained tool state, and reserved output space so this can be diagnosed.
Impact
This blocks reliable long-running agent work and creates direct usage waste. A production coordination thread became trapped in repeated compaction while repository progress stalled.
The reporter has screenshots showing the compaction events and the thread remaining about 80% full immediately afterward. Private repository names and paths are intentionally omitted from this public report.
Related reports
- #24948 — repeated compaction history and raw tool output cause huge session logs
- #34971 — massive cached context is repeatedly reprocessed, causing latency and excessive credit use
- #19585 — unusually fast usage depletion worsened by unstable context compaction
- #21134 — long active Codex Desktop threads remain unusable despite transcript pruning
- #29967 — auto-compaction occurs at the threshold and needs stronger pre-turn handling
This issue is narrower: the visible auto-compaction completes but immediately leaves the active thread around 80% full.
14 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Additional evidence and triage request:
The duplicate detector linked #34322, #34095, and #34971, confirming that repeat compaction, execution-frontier loss, cached-context reprocessing, and excessive usage are an existing failure class. This report adds a narrower, directly measurable symptom: Codex Desktop visibly reports successful auto-compaction, but the context meter immediately remains about 80% full, leaving only roughly 20% working headroom before the next compaction.
In the affected production thread, that resulted in repeated
Context automatically compactedevents, repeated planning/tool work, degraded acceptance-state retention, and exhaustion of included usage before the repository task completed.Requested maintainer triage:
No private repository names, paths, or account identifiers are included here.
Noticed this too, a 10-minute fix is getting 3 to 5 times longer it should have been
<img width="1307" height="1175" alt="Image" src="https://github.com/user-attachments/assets/311a1d58-f153-4ba4-b392-aa4ebf4f5486" />
Related but separate follow-up filed as #35037: Codex Desktop did not surface an active official OpenAI incident or offer a pause/bounded-handoff path while the affected long-running session continued consuming usage. #35032 remains the measurable post-compaction occupancy defect; #35037 covers incident observability and user protection.
Follow-on decomposition from the same production incident, consolidated to canonical issues so each defect has one maintainer discussion:
codex-securitydisappearance-after-update case has been added.Please keep #35032 focused on the measurable compaction invariant: a reported-success compaction immediately leaves the active thread near the next compaction threshold.
Thank you for the independent corroboration, @TeachDian. The 3–5× slowdown is the same user-impact class this report is trying to isolate. If convenient, the most useful additional diagnostics would be: Codex Desktop/app-server version, approximate context percentage immediately before and after the visible compaction event, number of compactions in the run, and whether the agent repeated the same plan/tool work afterward. Please keep repository names, account identifiers, and private transcript content redacted.
@TeachDian Thank you — your screenshot and the 3–5× duration increase are useful independent corroboration. If you can safely add them without exposing private work, the most diagnostic fields would be:
Context automatically compacted/Optimized the conversationevents;That would help maintainers distinguish the narrower post-compaction-occupancy failure in this issue from generic latency or the broader execution-frontier reports. Please keep repository names, paths, account IDs, and private task content redacted.
Thanks @TeachDian — that independent reproduction is useful, especially the same pattern of a small task stretching to several times its expected duration.
If you still have the affected session, the most useful extra telemetry would be:
Please redact account, repository, path, and credential details. The narrow invariant this issue is trying to preserve is measurable: a successful compaction should reclaim substantial working headroom rather than resume near the next threshold.
Redacted visual evidence is now available in a public evidence branch:
!Redacted Codex repeated-compaction chronology
The crop preserves the visible chronology of command activity followed by repeated
Context automatically compactedevents and the usage-exhaustion banner. Private repository names, paths, task narration, integration labels, and thread details are removed.Claim boundary: this image proves the visible event sequence and resulting exhausted-usage state. It does not by itself establish the internal token accounting or root cause; those remain the telemetry requests in this issue.
Evidence-link correction: the repository's release-hygiene check correctly rejected the branch-local SVG as a release-impacting asset. The redacted screenshot is now referenced through the immutable commit that created it, while the live branch keeps only the evidence manifest and incident SOP.
The earlier branch-local visual link is superseded by the immutable link above. The redaction and claim boundaries are unchanged.
@TeachDian Thanks for corroborating this. I’ve published a public-safe visual exhibit that strips private task, repository, integration, account, and session details while preserving the repeated
Context automatically compacted→ tool-operation sequence:https://github.com/grtninja/skill-arbiter/pull/8
The exhibit is deliberately narrow: it proves the repeated event pattern, not the server-side root cause. The most useful additional correlation from other affected users would be the Codex Desktop build, model/reasoning setting, visible context occupancy immediately before and after compaction, and whether the first post-compaction actions repeat already-completed work.
Maintainers: the report now has independent corroboration plus redacted visual evidence. Please expose pre/post compaction token accounting and add a circuit breaker when a successful compaction does not reclaim substantial working headroom.
Durable evidence/SOP update: the incident-reporting pull request has passed all protected checks and merged into
grtninja/skill-arbitermain.Merged policy commit:
af43f33de34b60216bbc0c4a4771d32e837425f6.Canonical-link correction for the incident-observability follow-up:
#35037was later closed as a duplicate of reopened#35038. The active incident-visibility/run-protection discussion is therefore #35038. The distinction remains unchanged: #35032 is the measurable post-compaction headroom defect; #35038 is the product incident-awareness, pause/handoff, and session-linked usage-review request.I reproduced the same failure mode on Codex Desktop for Windows.
Environment:
26.721.3996.0ChatGPT.exefile/product version:150.0.7871.12810.0.26200.05.6 Sol High258kcodex-cli 0.145.0Observed context sequence in the affected long-running task:
246k / 258k(95%)197k / 258k(76%)217k / 258k(84%)249k / 258k(96%)246k / 258k(95%)One 17m57s turn displayed three completed
Context automatically compactedevents and immediately entered a fourth. The task could not finish ordinary bounded research or orchestrate a subtask.A separate side conversation inheriting the same long history independently reproduced immediate re-compaction after very small operations:
codex --versiongh auth status(about 2.3s and 7 lines)No large tool output was emitted during these reproductions. This looks like insufficient durable headroom or retained-context accounting after compaction, not only a cosmetic context-meter issue.
I have sanitized screenshots and precise timestamps if maintainers need them, but they contain internal work context and should not be posted publicly without further redaction. Related report: #35226.