Repository navigation
Goal mode: agent cannot reconfigure or resume a paused goal after explicit user instruction #40162
Description
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_goalreports the existing Goal aspausedand unfinished.create_goalrefuses a replacement with:cannot create a new goal because this thread has an unfinished goal; complete the existing goal first.update_goalonly acceptscompleteorblocked; 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
- Create an active Goal with a time-based objective.
- Pause the Goal.
- Ask the agent to change the objective and restart it.
- Observe that
get_goalstill returnspaused. - Attempt
create_goalwith the corrected objective; it fails because the paused Goal is unfinished. - Observe that
update_goalexposes 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
- Goal objective cannot be edited by the agent after creation #31185: Goal objective cannot be edited by the agent after creation
- Expose Goal controls outside the interactive TUI, both for external automation and agent-side workflows. #31783: Expose Goal controls outside the interactive TUI
- Add wait/wake support for goals without spending tokens #28144: Add wait/wake support for goals without spending tokens
- Goal future-time waits spin for 100+ auto-continuation turns instead of handing off to heartbeat automation #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.
Activity
packagewjx commentedon Aug 28, 2026
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.
aidawilliam41-ops commentedon Sep 14, 2026
Additional observed case: an unfinished blocked goal in Codex Desktop on Windows, September 13–14, 2026.
The owner explicitly asked the agent to edit the goal, start it, and continue. The next
get_goal({})returnedstatus: "blocked"; a later read on September 14 still returnedblocked.The agent-visible tools exposed no operation for that requested edit/restart:
create_goalcreates an objective, but its contract disallows replacement while an unfinished goal exists.get_goalreads the current record.update_goalaccepts onlycompleteorblocked.No false completion or direct state-file edit was used. Ordinary task work could continue, but the agent could not perform the requested goal change through these tools.
Please include blocked goals in the supported owner-authorized edit/resume path requested here, preserving accumulated usage and the existing budget unless the owner separately changes it.
This observation concerns the exposed tool capability. It does not establish that the native Resume button was pressed or that a backend/UI resume action failed.