Paused Goal still receives automatic continuation turns until marked blocked

What version of Codex are you using?

Codex Desktop/current connected runtime; the exact app build was not discoverable from this session.

Platform

macOS 26.5.2 (25F84), Apple Silicon arm64.

What issue are you seeing?

A Goal whose persisted status was confirmed as paused continued to receive automatic internal Goal-continuation turns.

This is not the case where a user merely says "pause" in chat while the persisted Goal remains active. The Goal service returned status: "paused" before the unwanted continuations began.

Observed sequence:

1. The user paused the active Goal to discuss progress.
2. get_goal() returned the same thread Goal with status: "paused".
3. The runtime nevertheless injected:
   <codex_internal_context source="goal">Continue working toward the active thread goal...</codex_internal_context>
4. The agent declined to work and stated that it was honoring the explicit pause.
5. The runtime injected the same Goal continuation again.
6. After three consecutive unwanted continuations, the agent had to call update_goal(status: "blocked") merely to stop the loop.

No user request resumed the Goal between the paused-state observation and these continuation turns.

Expected behavior

• A persisted paused Goal must not schedule or inject any automatic continuation turn.
• It should resume only through an explicit supported user resume action.
• A user should not have to mark a healthy paused Goal blocked to suppress automatic continuation.
• The scheduler should re-check persisted Goal status immediately before enqueueing and immediately before injecting a continuation.
• If an already-enqueued continuation races with a pause, it should be cancelled or discarded when it observes paused.

Impact

• Consumes tokens while the user is intentionally discussing or waiting.
• Can cause unintended work after the user paused execution.
• Corrupts lifecycle semantics because blocked must be used as a workaround for paused.
• Makes long-running Goal work difficult to review safely.

Suggested acceptance criteria

1. Start an active Goal.
2. Pause it and verify its persisted status is paused.
3. Leave the thread idle across multiple continuation scheduling intervals.
4. Confirm no internal Goal-continuation turn is injected.
5. Resume explicitly and confirm continuation restarts normally.
6. Add a race test where pause occurs after continuation scheduling but before injection; the queued continuation must be dropped.
7. Keep paused and blocked semantically distinct.

Related issues

• #33827 reports the same "paused then continuation injected" signature on Windows, but combines it with browser restoration and a Desktop crash.
• #24531 concerns chat-level stop instructions while the persisted Goal remains active, which is distinct from this persisted-paused case.

Start with the Goal lifecycle entry points named in the report, get_goal and update_goal, then trace continuation scheduling and injection. Add coverage for the pause-before-injection race and verify that paused Goals produce no automatic turns, while explicit resume restarts continuation and paused remains distinct from blocked.