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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   automations

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

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

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

   

   github-actionsbot

   on Jul 20, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows: pausing Goal Mode still injects a continuation; restoring its in-app browser silently closes Codex #33827

   Powered by Codex Action

   👎React with 👎2Reacted by Gili Tzabari and Joe Simo
3. Owen-XRD commented on Jul 20, 2026

   

   Owen-XRD

   on Jul 20, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   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:

   • Windows: pausing Goal Mode still injects a continuation; restoring its in-app browser silently closes Codex #33827: a paused Goal still injects a continuation, after which Browser restoration correlates with Codex closing/restarting.
   • Goal auto-continuation can enter an unbounded no-progress loop and generate thousands of duplicate turns #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 (Windows: pausing Goal Mode still injects a continuation; restoring its in-app browser silently closes Codex #33827) and an hours-long active auto-requeue loop (Goal auto-continuation can enter an unbounded no-progress loop and generate thousands of duplicate turns #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.
4. maurocarraro commented on Aug 9, 2026

   

   maurocarraro

   on Aug 9, 2026 – with ChatGPT Codex Connector

   More actions

   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.
5. justin808 commented on Aug 28, 2026

   

   justin808

   on Aug 28, 2026

   More actions

   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.
6. mahogny commented on Sep 19, 2026

   

   mahogny

   on Sep 19, 2026

   More actions

   Additional manifestation on Linux, Codex CLI 0.155.0, model gpt-5.6-terra, with goals stable=true. This occurs across multiple unrelated local projects and sessions. After ordinary implementation progress, an active goal receives automatic continuation turns. Following repeated continuations without a newly identified safe edit, Codex terminalizes the goal with: "Goal marked blocked after repeated continuations without a safe new implementation step." There is no concrete external dependency or user decision preventing progress. Expected behavior: inspect current state and replan/continue, or ask to pause; set blocked only for a concrete external constraint. Goals are the primary workflow here, so disabling them is not a workable mitigation. Redacted session transcripts can be shared if useful.
7. joshmercer80 commented on Sep 30, 2026

   

   joshmercer80

   on Sep 30, 2026

   More actions

   Additional incident on macOS / Codex CLI in Ghostty, reported with the account owner's permission.

   Environment:

   • macOS 15.6.1, arm64; Ghostty terminal.
   • Currently installed CLI: codex-cli 0.155.1, checked on 2026-09-30. The exact CLI version during every earlier loop is not established.
   • A long-lived Goal thread, using GPT-6 Astra.

   Observed behavior:

   • Following a chat-level request to stop project work to conserve usage, automatic Goal continuation turns continued arriving.
   • Affected continuation turns ended with empty final responses and no tool calls or substantive project work. Repeated context compactions were also visible.
   • Cumulative Goal token accounting increased despite those no-progress turns.
   • The user later reported selecting Goal resume, seeing no useful progress, exhausting the weekly allowance, and using a reset. We cannot establish that this thread alone caused the full account-wide quota loss, or convert the cumulative Goal counter into billed/weekly usage.

   Important distinction: Goal status was verified as paused during the later diagnostic check. We do not have a verified persisted-paused state trace during the earlier loop, so this is not a claim that a confirmed paused Goal ignored its state.

   Expected behavior:
   The documented no-tool-call continuation safeguard should suppress further automatic turns, with a clear stopped/stalled state. Empty completions should not repeatedly restart work or consume additional usage. A natural-language stop and the separate Goal scheduler state should not misleadingly appear equivalent.

   Documentation: https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex
   Related empty-final report: #44735.

   No deliberate reproduction was attempted because of usage cost. No private conversation, project files, credentials, raw logs, screenshots, or session identifiers are attached.