Codex goal recovery is hard to discover and update instructions can become a replacement objective #29274

Summary

When a Codex goal becomes blocked, I sometimes cannot find a Resume button. Asking the assistant to unblock it produces an explanation that its goal tools cannot reactivate the goal, sometimes with instructions to use a Resume control I cannot see. This makes clearing and recreating the goal appear necessary.

I also need to update an existing goal as its requirements change. I want the assistant to revise the current objective using the conversation context, while preserving its progress and usage history. With the current command setup, instructions added after /goal can instead become a literal replacement objective. Exact /goal clear appears to work; the problem in this workflow is expressing an update without clearing and recreating the goal.

Environment

• T3 Code desktop and bundled server 0.1.6.
• Windows 11 x64, build 10.0.26100.
• Codex provider, gpt-6.1-sol.
• Observed in a long-running thread on 2026-11-01 and 2026-11-02. Times below are UTC.

Blocked goal and missing recovery controls

On November 1, the provider reported a blocked goal at 11:37:18.968. At 11:48:14 I asked the assistant to unblock it. Its response at 11:56:59 said its goal tools could not reactivate it and directed me to Resume on the goal card.

The 0.1.6 UI only renders Resume when presentation.canResume && !isWorking. This matches the conditional disappearance described in #25951. It supports a cause when the thread is working; historical UI visibility was not captured, so it does not prove every missing-button occurrence had that cause.

The backend can resume an existing blocked goal. At 12:06:16.241, T3 sent thread/goal/set with status: active. The resulting notification preserved the objective, 1,667,972 tokens used and 11,751 elapsed seconds. Deleting and recreating the goal was unnecessary in that instance. The assistant-facing limitation and available T3 controls need to be communicated consistently.

Updating an existing goal

On November 2 at 00:27:55, I asked the assistant to update the running goal with the latest details and instructions. At 00:28:22 it replied: "The goal API available here can change status but cannot edit an active goal's text." It saved the revised instructions in a project progress file instead. This establishes the assistant's reported limitation in that session, rather than proving that every underlying API lacks update support.

The /goal command path also treats unrecognized arguments as a replacement objective. It does not distinguish an instruction to revise the current goal from the complete text of a new goal.

Retained messages and provider requests show:

• /goal clear and set the new goal cleared the old goal and set the literal objective clear and set the new goal on November 1 at 08:14:37.
• /goal clear and create a goal for that similarly became the literal objective at 08:18:09.
• /goal continue, submitted on November 2 at 09:10:40, was processed at 09:10:43: it cleared the existing blocked goal, created the objective continue, and reset its usage counters. It did not resume the existing objective.
• Exact /goal clear subsequently produced thread/goal/clear and thread/goal/cleared at 09:10:56. It succeeded in that retained example.

The installed parser recognizes only the exact subcommands clear, pause, resume and edit after /goal; other arguments become objectives. Isolated evaluation of the installed parser confirms these outcomes. These examples show literal replacement behavior and explain the update ambiguity; they do not establish that an exact clear command is broken.

Reproduction scenarios

1. Open a Codex thread with an explicitly blocked goal and view the goal row at the timeline footer. Compare the available actions while idle and while another turn is running.
2. Ask the assistant to unblock the goal. Check whether its instructions lead to a visible recovery action in each state.
3. With an existing goal, ask the assistant to amend its objective using new details from the conversation. Check whether the persisted objective is actually updated, or the assistant reports that it cannot edit it.
4. Compare that with entering instructions after /goal: retained examples such as /goal continue and /goal clear and set the new goal replace the objective with the literal argument and reset usage counters.

These scenarios follow retained events and inspected code. No new goal was created, cleared or resumed during this investigation.

Expected behavior

Keep recovery controls accessible, or explain the action required to make them available. Guide the assistant to the actual /goal resume workflow when its own tools cannot reactivate a goal.

Provide a clear way to edit the existing goal using new instructions and conversation context. Updating should revise the persisted objective while preserving progress and usage history. Distinguish updating, resuming, clearing and replacing a goal, so an update request does not silently become the new objective verbatim. Show the supported actions and make any replacement explicit before discarding the existing goal's history.

Related reports

• #25951 and open, unmerged PR #26022: Resume is hidden during an active turn. Closest match for the missing control.
• #25954 and open, unmerged PR #26023: controls require scrolling to the end of long threads. Another possible discoverability issue; this specific trigger was not captured locally.
• #20232 and open, unmerged PR #20247: /goal resume can fail with EmptyInput. Related recovery failure, but that error was not established in the selected local resume examples.
• #13252: historical exact /goal clear dispatch failure, closed as completed. Exact clear succeeds in the retained 0.1.6 example, so this report does not establish a recurrence of that older bug.

The missing-control portion overlaps an existing open issue. The additional local evidence concerns Windows desktop 0.1.6, conflicting recovery guidance, an assistant reporting that it cannot edit the active objective, and instructions being treated as literal replacement objectives. Raw conversations, private goal contents and databases are not included.

Filed by

Prepared and submitted by GPT-6.1 Sol through the Codex harness in T3 Code, at the user's request. Supporting research used GPT-6.1 Terra and GPT-6.1 Sol agents. The t3 triage launcher was not run.