[Context] Repeated auto-compaction degrades execution frontier and prevents convergence in long tasks #34095

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   contextIssues related to context management (including compaction)Issues related to context management (including compaction)

   rate-limitsIssues related to rate limits, quotas, and token usage reportingIssues related to rate limits, quotas, and token usage reporting

   model-behaviorIssues related to behaviors exhibited by the modelIssues related to behaviors exhibited by the model

   on Jul 19, 2026
2. github-actions commented on Jul 19, 2026

   

   github-actionsBot

   on Jul 19, 2026 – with GitHub Actions

   Contributor

   More actions

   Potential duplicates detected. Please review them and close your issue if it is a duplicate.

   • Goal context is discarded during compaction, breaking objective continuation #32922

   Powered by Codex Action
3. Leviann

   changed the title [-][Rate Limits] Infinite compaction loop on gpt-5.6-sol (ultra reasoning) causes rapid quota exhaustion[/-] [+][Context] Repeated auto-compaction degrades execution frontier and prevents convergence in long tasks[/+] on Jul 19, 2026
4. Akshmit commented on Jul 21, 2026

   

   Akshmit

   on Jul 21, 2026

   More actions

   Ran into this non-convergence pattern as well, after repeated context compactions, long sessions would hit ~2GB memory usage and loop indefinitely while re-stating the same "final verification/commit" frontier. To handle this during multi-hour tasks, I'm building a lightweight watchdog utility that monitors compaction loops, rotates session logs, auto-terminates non-converging runs, and verifies genuine terminal state completion. I plan to open-source it tomorrow, let me know if you'd like me to share a link or tag you here once it's pushed!
5. planetzalex commented on Jul 23, 2026

   

   planetzalex

   on Jul 23, 2026

   More actions

   Why does this behavior exist even after they halved the context window? Bad things happening at OpenAI.

   To partially mitigate this absolute fucking bullshit-ass problem that still exists today, I added a compaction counter to every task and force a new task with a fresh context after three compactions. This is a stupid fix for a problem that should NEVER have existed.
6. grtninja commented on Jul 23, 2026

   

   grtninja

   on Jul 23, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows Codex Desktop evidence is in #35032. In the affected production thread, compaction visibly completed but left the session at roughly 80% context occupancy, after which plans and acceptance criteria began repeating while paid usage continued to fall. This supports the execution-frontier degradation reported here and adds a concrete post-compaction headroom measurement. A useful mitigation would be a circuit breaker that creates a bounded handoff when compaction cannot reclaim safe working space.
7. grtninja commented on Jul 23, 2026

   

   grtninja

   on Jul 23, 2026 – with ChatGPT Codex Connector

   More actions

   Independent corroboration and narrower telemetry case: #35032 reproduces the same execution-frontier/convergence failure in Codex Desktop on Windows, with the visible Context automatically compacted event followed immediately by roughly 80% context occupancy. The affected thread then compacted again after only a small amount of work, repeated plans/tool activity, and exhausted included usage before the repository task completed. Another user independently replied on #35032 that a ten-minute fix was taking three-to-five times longer. This supports the report here and adds a measurable post-compaction reclamation symptom.
8. GG95-lab commented on Sep 25, 2026

   

   GG95-lab

   on Sep 25, 2026

   More actions

   I've been running into a very similar problem in long Codex Desktop sessions, especially after repeated compactions.
   I ended up building a small Windows tool that tracks compaction/session health signals and creates a structured handoff into a fresh Codex session.

   I'm running a public beta here if anyone dealing with the same problem wants to try it:
   https://github.com/GG95-lab/FreshThread-BETA-version
9. oskaritooo commented on Sep 26, 2026

   

   oskaritooo

   on Sep 26, 2026 – with ChatGPT Codex Connector

   More actions

   Independent Windows Codex Desktop reproduction from 2026-09-26 that appears related to this issue. I am not claiming that compaction is proven to be the cause; I am adding this because the same non-convergence occurred in a run containing three automatic compactions, with a directly inspectable local JSONL.

   Environment

   • Codex Desktop / Windows
   • bundled CLI recorded in rollout: 0.155.0-alpha.9.2
   • model: gpt-6-luna
   • reasoning: xhigh
   • reported context window: 258400
   • session/thread ID: 01a0dcd4-d052-7a42-a396-01a02627051e
   • workspace: local engineering project controlling real IoT devices

   The affected root turn started at 2026-09-26T08:29:17Z and ended with a user interruption at 2026-09-26T10:19:20.868Z.

   The rollout records:

   turn_aborted
   reason: interrupted
   duration_ms: 6603042
   

   So the single turn ran for approximately 1 h 50 min 03 s before I stopped it manually.

   Compactions in the affected turn

   The local rollout contains three compacted events:

   • 2026-09-26T08:55:03.436Z
   • 2026-09-26T09:29:22.593Z
   • 2026-09-26T10:10:54.250Z

   Concrete non-convergence behavior

   The task was narrowly scoped: diagnose and fix physical ON/OFF control latency, with explicit instructions to verify the actual runtime and physical device rather than declaring success from unit tests.

   Early runtime traces already narrowed the cause space substantially. One representative early trace showed approximately:

   • click -> scheduler submit: ~1678 ms
   • scheduler queue wait: ~1 ms
   • worker lock wait: ~0.003 ms
   • P0 start -> physical WRITE: ~1731 ms
   • WRITE I/O: ~202 ms
   • P1 readback: ~161 ms

   A later P1 path showed ~2842 ms associated with uncertain-command-observation.

   In other words, the evidence already indicated that ordinary queue wait / worker-lock contention was not the main explanation for the observed end-to-end delay.

   Despite this, the run continued through additional instrumentation, more tests, runtime restarts, code changes (including commit 6f26da9), observer-load testing, and further trace inspection without reaching a stable diagnosis/terminal condition. I eventually aborted the turn.

   At the end of the turn, the local token counter recorded 22,250,946 total tokens including cached input. I am not treating that local counter as billed usage; it is included only to show the execution scale.

   Why I think this may be useful here

   This run is much shorter than the 24-compaction reproducer in the original report, but it shows a similar failure shape: the broad objective remained known, significant evidence was gathered, yet the execution did not efficiently converge and continued reopening/expanding diagnostic work across several compactions.

   I cannot establish from the client log alone whether the compactions caused the behavior. The session ID above should allow OpenAI to correlate this with server-side telemetry if useful.

   Report preparation disclosure

   I verified the session ID, CLI version, model/reasoning, compaction timestamps, turn duration, and termination directly from the local Codex JSONL. AI assistance was used to search/organize the records and draft this comment; AI is not the telemetry source.