I encountered a persistent no-progress loop in Codex Desktop while using Goal for a long-running engineering task.
After the task had resumed and was performing actual work, the assistant switched back to treating it as paused immediately after a context compaction event. Goal then repeatedly initiated new turns, and the assistant repeatedly responded that it remained paused.
The loop lasted approximately 5.5 hours until I manually intervened.
Environment
- Codex Desktop on macOS
- A long-running Goal with substantial conversation history
- Exact app and OS versions are pending confirmation
- Whether experimental context management was enabled at the time is not yet confirmed
Project details, account information, session identifiers, and infrastructure details are omitted for privacy.
Timeline
All times are September 8, 2026, Pacific Daylight Time (PDT, UTC−7).
- 09:21:56: I sent a plain-text “Pause” message in chat. This was not
/goal pause. - 09:22:37: The assistant confirmed that work and monitoring were paused.
- 09:48:12: The conversation received updated Goal context explicitly directing the task to resume.
- 09:48:22: The assistant stated that it was resuming and subsequently performed actual work.
- 10:45:26: The assistant was still reporting substantive task progress.
- 10:51:06: A context compaction event was recorded.
- 10:51:35: The assistant again stated that work was paused. I found no new manually entered pause message at this point in the conversation log.
- 10:51:43–16:25:27: Automatic continuations repeatedly produced “Remain paused” or equivalent replies.
- 16:25:27: I manually sent “Continue.”
- 16:25:32: The assistant resumed actual work, ending the loop.
Observed behavior
The repetitive segment contained:
- 3,994 pause-related assistant replies
- 3,992 execution turns
- 19 context compactions
- 5 hours, 33 minutes, and 44 seconds between the first and last repetitive replies
No engineering tool calls were observed during this segment.
The recurring pattern was:
Goal auto-continuation → assistant says it remains paused → turn ends → Goal immediately continues again.
Token accounting — not a billing claim
Local per-call usage records, supplemented by two corresponding token-count events, indicate approximately 896.8 million total tokens processed during the loop:
- Cached input: 888,645,504
- Uncached input: 8,042,862
- Output, including context-compaction output: 126,929
These figures were calculated from individual usage entries, not by repeatedly summing cumulative counters.
Most of this was cached input. These numbers do not establish the amount billed or the impact on my account quota. I have contacted support separately to request server-side verification.
Expected behavior
I understand that plain-text “Pause” may not be equivalent to pausing Goal through its controls. However, the task had subsequently resumed and was demonstrably making progress before switching back to a paused interpretation.
Regardless of how pause state is represented:
- A paused Goal should wait without repeatedly invoking the model.
- A resumed Goal should continue substantive work.
- Thousands of identical, non-progressing replies should trigger a stop or backoff rather than continue indefinitely.
Questions for investigation
- Could context compaction have caused the earlier pause instruction to override the later resumed state?
- Why did auto-continuation remain active while the assistant considered the task paused?
- Should repeated identical final replies trigger a no-progress safeguard?
The timing suggests a possible connection to compaction, but I cannot establish the internal root cause from local logs alone.
Support suggested clearing the Goal if the loop recurs and checking whether experimental context management was enabled. I have not deliberately reproduced the full loop because of its resource cost.
Has anyone encountered similar behavior? I can provide minimal, redacted log excerpts and identifiers through a private official support channel.
reaction to the GitHub issue itself, rather than only reacting to this forum topic. GitHub reactions can help the maintainers gauge how many users are affected.