You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Serious auto-compact bug: agent repeatedly enters a resume loop after conversation optimization. #34322
What version of the Codex App are you using (From “About Codex” dialog)?
26.715.52
What subscription do you have?
Pro
What platform is your computer?
No response
What issue are you seeing?
Serious auto-compact bug: agent repeatedly enters a resume loop after conversation optimization.
After auto-compact / “Optimized the conversation,” the agent resumes with near-identical status messages, re-reads the same files, then compacts again. It does not appear to preserve progress across the compact boundary.
The agent may also deny the loop (“Still connected, and no loop”) while repeating the exact same cycle.
Impact:
Task appears active but makes no real progress.
User prompts like “are you still connected?” can restart the loop.
The agent may repeatedly re-read files or resume the same plan instead of producing a handoff.
This has happened twice across my work.
Expected behavior:
After compaction, the agent should continue from the next concrete step, or stop with a handoff if state is insufficient. It should detect repeated compact/resume cycles and exit safely rather than looping.
Observed repeated pattern:
Agent says it will re-open/trace the active code path.
“Read files”
“Optimized the conversation”
Agent says it is still connected and will re-open the same code path.
I reproduced a narrower, directly measurable version of this loop on Codex Desktop for Windows: the UI reported Context automatically compacted, but the context meter immediately remained about 80% full. After only a small number of operations, compaction triggered again and the execution frontier repeated. I filed #35032 with the exact occupancy symptom and screenshots. That post-compaction occupancy may be useful telemetry for diagnosing the resume-loop behavior described here.
I am seeing the same failure repeatedly in Codex App 26.803.41515 on macOS (Darwin 25.5.0, arm64).
In a long-running project thread, the UI repeatedly shows “Optimized the conversation” instead of returning to the task. The loop continues until I force-stop the turn. If I then tell Codex that it is stuck and ask it to continue, it usually resumes, which makes this look like a compaction/resume loop rather than ongoing work.
This has occurred several times in the same project thread.
Feedback ID: 019f9efa-374d-7180-985d-98bd4f9e534f
Expected behavior: compact once and resume from the next concrete step, or surface a recoverable error. The app should detect repeated compaction attempts and stop the loop.
Activity
github-actions commentedon Jul 20, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
grtninja commentedon Jul 23, 2026
I reproduced a narrower, directly measurable version of this loop on Codex Desktop for Windows: the UI reported
Context automatically compacted, but the context meter immediately remained about 80% full. After only a small number of operations, compaction triggered again and the execution frontier repeated. I filed #35032 with the exact occupancy symptom and screenshots. That post-compaction occupancy may be useful telemetry for diagnosing the resume-loop behavior described here.gbonjack commentedon Aug 9, 2026
I am seeing the same failure repeatedly in Codex App 26.803.41515 on macOS (Darwin 25.5.0, arm64).
In a long-running project thread, the UI repeatedly shows “Optimized the conversation” instead of returning to the task. The loop continues until I force-stop the turn. If I then tell Codex that it is stuck and ask it to continue, it usually resumes, which makes this look like a compaction/resume loop rather than ongoing work.
This has occurred several times in the same project thread.
Feedback ID:
019f9efa-374d-7180-985d-98bd4f9e534fExpected behavior: compact once and resume from the next concrete step, or surface a recoverable error. The app should detect repeated compaction attempts and stop the loop.
Beerbill commentedon Aug 11, 2026
literally burning tokens into this loop behavior