Automatic continuation loop consumed tokens without making progress #37800

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   agentIssues related to the core agent loopIssues related to the core agent loop

   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 Aug 10, 2026
2. github-actions commented on Aug 10, 2026

   

   github-actionsbot

   on Aug 10, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Goal resume enters endless loop #37304
   • Unattended session ran 16.5h from one prompt: 7,395 requests, 4.2B tokens, no interrupt path, unrecoverable auth end (codex-cli 0.146.0) #37282
   • Desktop wait/status orchestration re-meters full cached context every 10-30s; stale 'running' subagents keep it looping (90% of weekly Pro in 15.5h) #37299

   Powered by Codex Action
3. andjones132 commented on Aug 30, 2026

   

   andjones132

   on Aug 30, 2026

   More actions

   Additional deterministic evidence — active Goal continuation self-interrupt loop

   FACT — environment/task/host/revision

   • Observed 2026-08-30 UTC on a private Linux host (KVM-202-LAN).
   • Codex CLI/App Server: 0.147.0.
   • Affected task: 01a050f3-96f5-72a0-8e78-7f360275aa17.
   • Reporter/verification task: 01a054d0-5fb6-71c2-910f-38cbc1a489d5.
   • Interface: native Goal runtime and App Server thread/goal/get / thread/goal/set over its documented local WebSocket transport.
   • No credentials, prompt contents, or private attachment paths are included.

   Prerequisites

   1. A loaded Codex task with an active Goal.
   2. A continuation is scheduled while the prior turn is still busy or being interrupted.

   Exact reproduction steps

   1. Initialize an App Server client and call:

   {"method":"thread/goal/get","id":1,"params":{"threadId":"01a050f3-96f5-72a0-8e78-7f360275aa17"}}

   2. Confirm the returned goal has status="active". In this case the objective was a stale local attachment-read instruction; its path and contents are redacted.
   3. Leave the goal active and observe the task rollout. The runtime repeatedly appends an internal user message with source="goal" while the preceding turn is busy, then records turn_aborted, then immediately starts another turn.
   4. Count event types deterministically in the local JSONL rollout. At the repair point the task contained:

   task_started:       2816
   turn_aborted:       2806
   goal user messages: 2806
   first goal message: 2026-08-30T04:36:49.892Z
   last goal message:  2026-08-30T22:40:49.488Z
   

   5. Pause without changing the objective or accumulated usage:

   {"method":"thread/goal/set","id":2,"params":{"threadId":"01a050f3-96f5-72a0-8e78-7f360275aa17","status":"paused"}}

   6. Re-run thread/goal/get: status is paused; objective and tokensUsed=225531 remain preserved.
   7. Compare turn_aborted over an 8-second deterministic observation: 2803 -> 2803 at the immediate repair check. No metered model polling was used.

   Expected result

   An automatic continuation must atomically check task/turn state. It should wait for the active turn, coalesce with an already queued continuation, or stop with an actionable error. It must not arrive as busy input that aborts the turn it is intended to continue.

   Actual result (verbatim, secret-redacted)

   The repeating sequence was:

   response_item role=user source="goal"
   turn_aborted
   task_started
   

   This repeated thousands of times without completing the stale objective.

   Impact/severity

   HIGH. The task made no useful progress for an approximately 18-hour event span, generated 2,806 aborts/automatic Goal messages, and required an out-of-band task-scoped pause to stop the storm.

   Remediation attempts and outcomes

   1. Sampled task status. Result: repeatedly active/interrupted with no progress.
   2. Searched local automations. Result: no matching automation.
   3. Parsed the exact task rollout. Result: identified the automatic Goal-message/abort/start cycle.
   4. Read native Goal state. Result: active stale attachment objective, tokensUsed=225531.
   5. Set only status="paused", omitting objective. Result: objective/usage preserved.
   6. Compared abort counts over 8 seconds. Result: stable; already-running work could finish aborting, but no new burst was scheduled.

   INFERENCE

   The Goal scheduler likely lacks an atomic idle/in-progress guard or continuation coalescing. Incoming automatic continuation is then treated as busy user input and interrupts the turn. This requires code evidence to confirm.

   UNKNOWN

   • Exact scheduler/state-machine race.
   • Whether all transports/hosts are affected.
   • Billing/usage impact of aborted automatic turns.
   • Whether a stale attachment objective is causal or only incidental.

   Evidence/receipts

   • Task-scoped Goal pause receipt: status=paused, objective and usage preserved.
   • Immediate abort counter receipt: 2803 -> 2803 over 8 seconds.
   • Full aggregate counts and timestamps above came from the affected task's local JSONL rollout.

   Reporter task ID and direct reply route

   • 01a054d0-5fb6-71c2-910f-38cbc1a489d5
   • GitHub: @andjones132

   Verification required to close

   Reporter-side verification should recreate the original active-goal/busy-turn condition, assert that automatic continuations coalesce or wait, and confirm zero self-induced turn_aborted events. An owner-side patch alone is not sufficient.
4. andjones132 commented on Aug 30, 2026

   

   andjones132

   on Aug 30, 2026

   More actions

   Post-repair receipt/correction (2026-08-30 UTC):

   • The task still has exactly 2,806 automatic messages containing <codex_internal_context source="goal">.
   • The last automatic Goal message was 2026-08-30T22:40:49.488Z, 1.534 seconds after the status=paused update at 22:40:47.954Z, consistent with one already-queued continuation.
   • No later automatic Goal continuation is present.
   • Later turn_aborted records at 22:50, 23:03, and 23:06 were paired with explicit user/delegated messages, not source="goal"; they must not be counted as recurrence of the automatic scheduler storm.
   • The task is currently idle. The stale Goal objective and usage remain preserved rather than cleared.

   This verifies the pause as an effective containment, not a product fix. Reporter-side reproduction against a candidate scheduler fix remains required before closure.