[Bug] Persistent goal runs for over a day while repeatedly planning instead of delivering

[jimicze]

Summary

A persistent Codex goal remained active for more than 37 hours and consumed millions of tokens, but repeatedly generated specifications, plans, and documentation instead of delivering the requested usable Chrome extension UI.

The user eventually had to redefine and re-establish the goal manually.

Uploaded thread: 019f78cf-a24c-7f30-80ac-c32b3ccfc887

Timeline

• 2026-07-19 05:39 UTC: The original implementation goal became active.
• 2026-07-20 10:10 UTC: The goal remained active after roughly 29 hours and reported 6,300,749 tokens used.
• The run continued producing release plans and specifications, including closed-shadow and recorder design documents.
• 2026-07-20 18:39–18:44 UTC: The user explicitly reported that the run had exceeded one day, was still planning, and had not delivered the product.
• 2026-07-20 19:15 UTC: The goal appeared re-established with an added PRD/TASKS instruction and a reset usage counter of 322,983 tokens.
• The user later had to restate the original product goal because the implementation had drifted into an engine-heavy backend without the required usable UI.

Steps to Reproduce

1. Create a broad implementation goal requiring research, planning, implementation, and a verified user-facing product.
2. Allow persistent automatic goal continuations to run for many turns.
3. Observe repeated creation and revision of specifications, implementation plans, release documents, and internal architecture.
4. Observe that the run continues despite little or no progress on the central user-visible acceptance criteria.
5. Interrupt after more than one day and restate or recreate the goal to recover execution focus.

Actual Result

• Repeated planning and specification cycles.
• No enforced transition from planning to implementation.
• No automatic detection of scope drift.
• No useful stalled-progress warning.
• No completion or blocked-state resolution.
• The user had to interrupt, reconstruct the objective, and establish the goal again.

The goal continuation instructions explicitly said that plan updates must not substitute for doing the work and that the original scope must not be narrowed. The observed behavior still did both.

Expected Result

A persistent goal should:

• Preserve the original user-visible acceptance criteria.
• Detect repeated planning without corresponding implementation progress.
• Require concrete implementation after a bounded planning phase.
• Warn when time or token consumption grows without measurable product progress.
• Pause and request direction when scope materially drifts.
• Preserve goal state without requiring the user to recreate it.

Impact

• More than a day of unattended execution without the requested deliverable.
• Millions of tokens consumed while progress was misaligned with the product goal.
• Large volumes of plans, tests, and backend work gave a false impression of completion.
• The user lost visibility into current status and had to reconstruct the project objective manually.

Environment

• Codex CLI: 0.144.6
• Platform: macOS
• Date range: 2026-07-19 through 2026-07-20
• Repository: selectorChromePlugin
• Persistent goal with unbounded token budget
• Multi-agent execution enabled

Suggested Fix

Add a goal-progress watchdog based on deliverable evidence rather than turn count:

• Limit consecutive plan/spec-only continuations.
• Track implementation commits, changed production files, and verified user-facing outcomes.
• Detect repeated re-planning of already-planned work.
• Surface elapsed time, token use, completed deliverables, and remaining acceptance criteria.
• Require explicit user approval before materially narrowing the original product scope.
• Preserve and expose goal identity across resets or re-establishment so unexpected counter resets are diagnosable.

This is separate from the synchronous spawn_agent hang reported in #34653.

[github-actions]

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

• Goal auto-continuation can enter an unbounded no-progress loop and generate thousands of duplicate turns #34248
• GPT-5.6 Sol entered a repetitive agent loop and consumed ~80% of a freshly reset usage allowance #34395

Powered by Codex Action

[jimicze]

Scope clarification after reviewing #34248, #34395, and the related reports from this thread:

This is a separate persistent-goal alignment and deliverable-progress failure.

• Goal auto-continuation can enter an unbounded no-progress loop and generate thousands of duplicate turns #34248 reports a tight scheduler loop with thousands of nearly identical no-op replies requeued within milliseconds.
• GPT-5.6 Sol entered a repetitive agent loop and consumed ~80% of a freshly reset usage allowance #34395 reports a repetitive action loop and rate-limit/usage depletion.
• This report contains varied planning, specification, testing, and backend activity over 37+ hours, but the active goal semantically drifted away from its user-visible acceptance criteria. The user then had to reconstruct/re-establish the goal.

The requested fix is therefore different: preserve goal identity and acceptance criteria, measure progress against actual deliverables, detect scope narrowing, and stop plan-heavy activity that does not make the requested end state true. This is not an identical-output scheduler loop or only a usage-accounting report.