Goal auto-continuation can enter an unbounded no-progress loop and generate thousands of duplicate turns

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

• #33827

Powered by Codex Action

Support escalation and duplicate clarification — 2026-07-20

OpenAI Support case 11775178 is open and has received the private account-impact evidence. The latest support response suggested sign-out, restart, and network troubleshooting, but those steps do not address the scheduler evidence described in this issue.

The bot linked #33827. The two reports may share a Goal state-machine boundary, but they are not duplicates in their observed failure mode:

• #33827: a paused Goal still injects a continuation, after which Browser restoration correlates with Codex closing/restarting.
• #34248: no Browser Use or app-crash trigger is required. While an ordinary long-running task was waiting on an external process, each completed no-progress turn was requeued 5–8 ms later. The result was 7,480 Goal turns over 10:37:57 and 4,857 identical replies averaging one every 4.472 seconds, with substantial usage impact.

This issue therefore adds an unbounded no-progress continuation loop, duplicate-output failure, and usage-circuit-breaker failure. It also records that create_goal was invoked without an explicit user request to enable Goal mode.

Requested maintainer action:

1. Triage this under Goal/orchestration and keep it open or link it to a specific engineering tracker.
2. Investigate why ordinary continuation language could result in persistent Goal activation without explicit user consent.
3. Add no-progress detection, duplicate suppression, backoff, a consecutive-continuation cap, and a token/credit anomaly cutoff.
4. Preserve the distinction between a post-pause stale continuation (#33827) and an hours-long active auto-requeue loop (#34248).

Private session and account evidence remains with Support and is intentionally not posted publicly. The case number is provided only for OpenAI's internal correlation.

I reproduced the same failure mode in Codex Desktop on macOS: after each assistant completion, the runtime immediately reinjected <codex_internal_context source="goal"> with no new user message. It continued even after blank/no-op final responses, producing a self-sustaining sequence of Goal continuation turns.

Local evidence:

• the injection was not initiated by a local scheduler or an external event;
• a local router classified it as NOOP_INTERNAL_CONTINUATION and did not start work, but that did not prevent the next product-side injection;
• a later attempt to protect usage by marking the Goal blocked left it unrecoverable through the available programmatic goal API (new goals were rejected as an unfinished goal).

This looks specifically aligned with the task_complete -> task_started -> internal goal injection behavior described here, not merely normal context compaction. The needed product-level safeguard seems to be a circuit breaker that caps consecutive no-progress continuations and requires a real user/material trigger before requeueing.

I can provide a private session identifier and timestamped evidence to OpenAI if useful.

Reproduced on macOS with Codex App 26.820.60940, bundled codex-cli 0.150.0-alpha.8, on Apple Silicon (Darwin 25.6.0). Session/thread ID: 01a02d90-0a8d-7220-a38c-2f415a216a2f.

In this reproduction, the user paused a long-running Goal while its initial tool-heavy turn was active. The agent produced one correct restart handoff, but Goal auto-continuation then generated repeated paused/no-progress final messages every few seconds without new user input. After the repeated-blocker audit, the agent reported that it had marked the Goal blocked, but automatic continuations still continued for days. Later continuations became normally completed turns with no user-visible items.

This adds two observations to the existing report:

• Persisting/reporting blocked did not stop the scheduler in this session.
• The loop degraded from duplicate visible messages into successful empty turns rather than tripping a no-progress circuit breaker.

The task content involved a private repository and is intentionally omitted. OpenAI can inspect the session ID above. The scheduler guard needs to be outside model behavior: recheck persisted paused/blocked state before enqueue and injection, invalidate queued continuations on state transition, and stop after repeated no-tool/no-state-change or empty completions.