Blocked goal does not transition back to active when user resumes and agent continues work

I can reproduce the blocked-goal resume issue described here in Codex Desktop on Windows, with an additional timing/lifecycle problem.

Observed flow:

1. A running goal invokes a Skill that needs additional information from the user.
2. The goal enters the blocked/waiting state.
3. The user provides the requested information.
4. Codex resumes and continues the remaining work.
5. The goal still remains displayed as blocked.

In addition to the stale blocked status, the goal's displayed end time/duration stops at the moment the Skill requested user input. The resumed portion of the lifecycle is not included:

Included:     Goal started -> Skill requested user input
Not included: User replied -> Goal resumed -> Remaining work completed

Expected behavior:

• Supplying the requested information should resume the goal from blocked to running/active.
• After the remaining work finishes, the goal should transition to completed.
• The final end time/duration should cover the complete lifecycle, including execution after the user's reply.

Environment:

• Product: Codex Desktop
• Platform: Windows
• Date observed: 2026-07-13 (UTC+8)

This looks closely related to the missing blocked-to-active transition reported here, but it also affects the accuracy of goal lifecycle timestamps and duration.

I can independently reproduce this on Codex Desktop for Windows (observed 2026-07-27), and I would frame the requested remedy primarily as a missing goal-lifecycle feature/API transition rather than only a UI bug.

Observed sequence:

1. A long-running goal encountered a genuine external blocker (a required toolchain was absent).
2. After the blocking condition repeated, the agent correctly marked the goal blocked under its goal-management instructions.
3. The user installed the toolchain and explicitly asked the agent to continue.
4. Work genuinely resumed and completed meaningful validation (including a focused suite of 66 passing tests).
5. get_goal still returned status: blocked.
6. The agent-facing update_goal contract exposed only complete and blocked; it offered no supported active, resume, or unblock transition. Creating a replacement goal would also be inappropriate while the original goal remains unfinished.

Suggested feature shape / acceptance criteria:

• Expose an explicit, idempotent resume_goal action or support update_goal({status: "active"}) from blocked.
• Permit that transition after a user resume request or a recorded resolution of the blocking condition.
• Keep an audit trail such as blocked reason/time and resumed actor/time rather than erasing the blocked interval.
• Update persisted goal state, get_goal, automatic-continuation behavior, and the Desktop status strip atomically.
• Keep complete terminal unless reopening completed goals is designed separately.

No private repository, command, path, or goal-objective details are included here.

Confirmed independently with a long-running Codex Desktop Goal. This appears to be persisted lifecycle state drift, not only stale UI rendering.

Environment

• Product: Codex Desktop
• Platform: macOS
• Codex CLI version recorded by the session: 0.145.0-alpha.18
• Goal/session date: 2026-08-26 UTC

Observed sequence

1. A Goal was created and ran normally as active.
2. At approximately 05:46 UTC, the agent encountered a legitimate external authentication blocker and called update_goal({ status: "blocked" }).
3. The resulting persisted state was:

``text
status: blocked
tokensUsed: 509771
timeUsedSeconds: 13890
updatedAt: 2026-08-26 05:46:42 UTC
``

1. At approximately 05:56 UTC, the user resolved the blocker and replied done in direct response to the agent's request.
2. Codex confirmed that authentication was restored and resumed work toward the same Goal. It performed additional diagnostics, monitored the running workload, modified implementation files, and continued through later stages of the original objective.
3. Despite that work, get_goal() continued to return the original Goal as blocked, with the same tokensUsed, timeUsedSeconds, and updatedAt values shown above.
4. The agent later attempted to recreate the Goal with the same objective, but create_goal correctly rejected it because the thread still had an unfinished Goal:

``text
cannot create a new goal because this thread has an unfinished goal;
complete the existing goal first
``

1. The session continued doing Goal-related work for many hours, while the persisted Goal record remained frozen in the blocked state.

I am not posting the raw rollout because it is very large and contains workspace-specific operational context, but I can provide additional sanitized event extracts if useful.

Source-level diagnosis

The current behavior appears internally consistent once the Goal reaches blocked, but there is no supported agent-side transition back to active:

• codex-rs/ext/goal/src/spec.rs exposes update_goal.status with only complete and blocked.
• codex-rs/ext/goal/src/tool.rs rejects active and says pause/resume transitions are user- or system-controlled.
• codex-rs/ext/goal/src/extension.rs attaches turn accounting only when the persisted status is active or budget_limited.
• codex-rs/ext/goal/src/runtime.rs schedules automatic continuation only for an active Goal.
• codex-rs/state/src/runtime/goals.rs allows create_goal to replace an existing Goal only when its status is complete, so recreation cannot recover a blocked Goal.
• The app-server thread/goal/set path can set the existing Goal to active, but a normal user message that explicitly resolves the blocker does not invoke that transition, and the model-facing Goal tools cannot invoke it either.

Consequently, after the user explicitly resolves a blocker, the agent can resume ordinary turn execution while all Goal-specific state remains stopped:

user explicitly resumes work
        |
        v
ordinary turn runs and performs Goal work
        |
        +--> persisted Goal remains blocked
        +--> Goal token/time accounting remains frozen
        +--> Goal update notifications remain stale
        +--> automatic Goal continuation remains disabled

Expected behavior

An explicit user resume should atomically transition the same persisted Goal from blocked to active before Goal work continues. The transition should:

1. Preserve the Goal ID, objective, token budget, accumulated token usage, and accumulated elapsed time.
2. Persist blocked -> active and update updatedAt.
3. Associate the resumed turn with the Goal so subsequent token/time accounting is recorded.
4. Emit the normal thread/goal/updated event so every client clears its blocked presentation.
5. Restore automatic idle continuation after the resumed turn.
6. Be auditable in the rollout.

Suggested implementation direction

Either of these would close the lifecycle gap:

Option A: explicit agent-side resume tool

Add a narrowly scoped resume_goal tool that:

• succeeds only when an existing Goal is in a resumable stopped state such as blocked;
• is called only after the user's latest input explicitly resumes the Goal or resolves the requested blocker;
• transitions the existing Goal to active without replacing it;
• marks the current turn as Goal-active;
• emits the persisted Goal update event; and
• returns the same structured Goal/accounting fields as get_goal.

This keeps terminal update_goal semantics unchanged and makes the resume action explicit in the transcript.

Option B: explicit resume intent on turn submission

Add a typed resume signal to the user/client turn-submission path. Desktop, TUI, mobile, and noninteractive clients would send that signal when the user chooses Resume or explicitly submits a resume action. The Goal extension would consume it before turn accounting begins and transition the existing Goal to active.

This avoids relying on free-text matching in the runtime, but every client surface must support the signal.

I would avoid automatically resuming every blocked Goal on any user message, because an unrelated question or status request should not silently restart autonomous continuation.

Regression coverage

A regression test should cover the complete lifecycle:

1. create an active Goal;
2. account some usage;
3. mark it blocked;
4. submit an explicit user resume;
5. assert that the same Goal ID becomes active and previous usage is preserved;
6. record more token/time usage and assert that accounting increases;
7. stop the resumed turn and assert that automatic Goal continuation is eligible again; and
8. assert that ordered thread/goal/updated notifications contain the resumed active state.

This occurrence matches the core behavior described in this issue: the agent resumed real work after the user removed the blocker, but the Goal state and accounting remained one-way blocked.