Codex Desktop: resumed Goal ignores updated objective and rapidly loops no-progress continuations

Codex App Bug Report

What version of the Codex App are you using (From “About Codex” dialog)?

26.818.41509 (Windows Desktop release recorded by the app log during the reproduction)

What subscription do you have?

ChatGPT Pro.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Resuming a Goal in Codex Desktop can enter a rapid no-progress auto-continuation loop when an earlier ordinary chat message asked to pause part of the work, even though the persisted Goal objective was subsequently updated to continue that work.

In this reproduction:

• An earlier ordinary user message said not to run the test phase yet.
• The persisted Goal was then updated to require finishing the implementation, running a real agent skill-only test, and then running a controlled A/B test.
• The agent eventually marked the Goal blocked while respecting the earlier temporary pause.
• The user explicitly resumed the Goal from the Desktop Goal control.
• Every automatic continuation contained the updated Goal objective requiring the tests.
• Nevertheless, the model repeatedly answered that testing was still paused and it was waiting for an instruction to resume.
• Because the persisted status remained active, each normally completed turn immediately triggered another Goal continuation.
• The loop stopped only when the user manually pressed Pause.

Observed sanitized outputs included:

Goal remains paused, waiting for you to explicitly resume testing.
Still pausing testing as requested; no real Agent or A/B test was started.
Pause state unchanged; waiting for you to explicitly resume testing.
Continuing to pause as instructed; no tests were started.
Testing is still paused; no new operation was performed.
Remaining paused, waiting for your next instruction.
Testing remains paused; no new operation was performed.

This was real execution, not only a stale spinner:

• 7 separate task_started events
• 7 matching task_complete events
• duration: approximately 31 seconds
• Goal token counter before the loop: 320,265
• Goal token counter when manually paused: 357,282
• increase: 37,017 tokens
• no turn error, provider error, approval wait, application crash, or unmatched turn

Session/thread ID: 01a03c4e-1bab-7a73-bf91-f4948ff3f71a

What steps can reproduce the bug?

1. In Codex Desktop, create an active Goal with multiple phases, including a later test phase.

2. Send an ordinary chat message temporarily instructing Codex not to run the test phase yet, while allowing the earlier phase to finish.

3. Update the persisted Goal objective so it explicitly requires continuing with the test phase, for example:

   Finish the current implementation, then run a real agent skill-only test,
   then run a controlled A/B test.
   

4. Let the Goal stop as blocked/paused while it is still honoring the earlier temporary chat instruction.

5. Use the Desktop Goal control to Resume the Goal without sending an additional ordinary chat message.

6. Observe that the continuation payload contains the updated Goal objective, but the model says that work remains paused.

7. Observe a new automatic Goal turn immediately after every normally completed no-progress turn.

8. Manually press Pause to stop the loop.

Sanitized event sequence from the reproduction (UTC):

2026-08-26T17:12:19Z thread/goal/set -> active
2026-08-26T17:12:20Z automatic Goal turn 1 started
2026-08-26T17:12:25Z turn 1 completed; turn 2 immediately started
2026-08-26T17:12:30Z turn 2 completed; turn 3 immediately started
2026-08-26T17:12:33Z turn 3 completed; turn 4 immediately started
2026-08-26T17:12:38Z turn 4 completed; turn 5 immediately started
2026-08-26T17:12:41Z turn 5 completed; turn 6 immediately started
2026-08-26T17:12:48Z turn 6 completed; turn 7 immediately started
2026-08-26T17:12:50Z user manually set Goal -> paused
2026-08-26T17:12:51Z turn 7 completed; no further continuation

A second unattended reproduction was intentionally not run because the captured session already contains the full state transition and repeating lifecycle, and allowing the loop to continue would consume additional tokens.

What is the expected behavior?

• Resuming a Goal should be represented to the model as an explicit user resume action.
• The resume action should supersede an older pause/wait instruction for the same work, especially when the persisted Goal objective explicitly requires that work.
• A Goal should not create unbounded immediate continuations when consecutive turns make no progress.
• After a small number of semantically identical no-progress turns, the runtime should automatically suspend/pause the Goal with a visible reason instead of relying exclusively on the model to call update_goal(status: "blocked").
• No additional continuation should run until an explicit user action or relevant external-state change occurs.

Additional information

This appears to involve two interacting control-plane gaps in the current Goal runtime:

1. On a status-only transition from paused/blocked to active, apply_external_goal_set() calls continue_if_idle(), but a dedicated resume steering item is not injected when the objective text itself is unchanged at the moment of resume. The model therefore cannot reliably distinguish an explicit user Resume action from an ordinary continuation and may continue following an older pause message.
2. on_thread_idle() immediately calls continue_if_idle() while the persisted status remains active. Normal no-progress completion is not a terminal condition, and there is no deterministic repeated-output/no-tool/no-state-change circuit breaker.

Potential duplicate review:

• Automated triage suggested #40162.
• #40162 is related but not a duplicate. It reports a goal-tool capability dead end: the agent cannot edit or resume a paused Goal and the user must delete or manually reconfigure it.
• In #40929, the Desktop UI successfully persisted the updated objective and changed the Goal to active; the updated objective was present in every continuation payload. The distinct failure happens afterward: resumed turns continue obeying an older chat-level pause instruction, and app-server immediately launches repeated normally-completed no-progress turns.
• Therefore #40162 primarily needs an agent-accessible reconfigure/resume API, while #40929 needs explicit resume steering plus a deterministic no-progress continuation circuit breaker.

Related reports:

• #37304 reports the same visible “still paused after resume” loop, but does not include the Codex App Issue Form fields, Windows Desktop state transitions, updated-objective evidence, or measured token impact.
• #34248 tracks the broader unbounded no-progress Goal continuation problem.
• #24531 covers a related chat-level stop instruction while the persisted Goal remains active.

Suggested acceptance criteria:

1. Add a regression test for blocked/paused -> active with an unchanged objective and an older chat-level pause instruction.
2. Verify that resume-specific steering reaches the first continuation.
3. Verify that the first resumed turn proceeds with the current Goal instead of repeating the old pause.
4. Add a deterministic no-progress circuit breaker for repeated Goal-triggered turns with no tool calls, no external-state change, and equivalent final intent.
5. Verify that automatic suspension does not require a successful model-issued update_goal call.

Start by locating apply_external_goal_set(), continue_if_idle(), and on_thread_idle() in the Goal runtime. Trace the paused/blocked-to-active transition and the idle continuation path, then find the existing Goal regression-test area. Done means a resume-specific steering item reaches the first continuation and repeated no-progress turns trigger automatic suspension without requiring a model-issued update_goal call.