Goal mode: agent cannot reconfigure or resume a paused goal after explicit user instruction

Open 💬 1 comment Opened Aug 23, 2026 by adriansavage

Codex version

Codex 0.147.0, using the desktop app with a remote Linux workspace.

Deficiency

An agent cannot recover a paused Goal when the user explicitly asks it to change the objective and restart the Goal.

The available goal tools create an impossible lifecycle state:

  • get_goal reports the existing Goal as paused and unfinished.
  • create_goal refuses a replacement with: cannot create a new goal because this thread has an unfinished goal; complete the existing goal first.
  • update_goal only accepts complete or blocked; it explicitly cannot edit, cancel, pause, or resume a Goal.
  • Marking the Goal complete would be false because its objective was not achieved.
  • Marking it blocked would also be false and still would not provide an edit/replacement path.

In this incident, the user explicitly instructed the agent to change a recurring monitoring Goal from reports at :00/:30 to :05/:35, extend it to 10:05, and restart it. The agent could not perform that authorized change. The user ultimately had to delete the Goal manually before the agent could create the corrected Goal.

Reproduction

  1. Create an active Goal with a time-based objective.
  2. Pause the Goal.
  3. Ask the agent to change the objective and restart it.
  4. Observe that get_goal still returns paused.
  5. Attempt create_goal with the corrected objective; it fails because the paused Goal is unfinished.
  6. Observe that update_goal exposes no valid operation for the requested edit/restart.

Expected behavior

After explicit user authorization, the agent should have one supported, atomic recovery path, such as:

  • update the objective and resume the existing Goal; or
  • cancel/supersede the paused Goal and create its replacement.

The API should preserve the strict safeguards around falsely marking goals complete or blocked. It should not force the agent to misuse those states or invent a parallel shell-based scheduler while waiting for the user to operate UI controls.

For future-time monitoring Goals, the platform should also provide a wait/wake mechanism that does not consume active turns or require long-running polling commands.

Related issues

  • #31185: Goal objective cannot be edited by the agent after creation
  • #31783: Expose Goal controls outside the interactive TUI
  • #28144: Add wait/wake support for goals without spending tokens
  • #28923: Goal future-time waits spin instead of handing off to heartbeat automation

This report is specifically about the combined recovery dead-end after an explicit user request to reconfigure and restart a paused Goal.

View original on GitHub ↗

1 Comment

packagewjx · 4 hours ago

I also need this feature. Codex polls the build task, but if the build takes too long to complete, it suspends the goal. As a result, when the build finally finishes, it doesn't resume automatically. I have to manually instruct it to continue and resume the goal every single time.