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

Start by reproducing the persistent-goal scenario described in the Steps to Reproduce using Codex CLI 0.144.6 behavior and the uploaded thread 019f78cf-a24c-7f30-80ac-c32b3ccfc887. Trace goal continuations, progress evidence, scope changes, and state across resets. Done means stalled planning is detected and surfaced, scope drift requires direction, progress and usage remain visible, and goal identity is preserved.

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.