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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on Jun 21, 2026
2. ChenTingToDo commented on Jul 13, 2026

   

   ChenTingToDo

   on Jul 13, 2026 – with ChatGPT Codex Connector

   More actions

   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.

   👍React with 👍2Reacted by ChenTingToDo and James Wyse
3. BlakeMasters commented on Jul 27, 2026

   

   BlakeMasters

   on Jul 27, 2026 – with ChatGPT Codex Connector

   More actions

   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.
4. neverdie88 commented on Aug 27, 2026

   

   neverdie88

   on Aug 27, 2026

   More actions

   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:

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

   4. At approximately 05:56 UTC, the user resolved the blocker and replied done in direct response to the agent's request.

   5. 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.

   6. Despite that work, get_goal() continued to return the original Goal as blocked, with the same tokensUsed, timeUsedSeconds, and updatedAt values shown above.

   7. 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:

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

   8. 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.
5. perdurabo93 commented on Oct 10, 2026

   

   perdurabo93

   on Oct 10, 2026 – with ChatGPT Codex Connector

   Last edited by perdurabo93

   More actions

   Additional occurrence on Windows, observed October 10, 2026, reported at the user's request.

   After the user explicitly said resume now, the same Codex desktop chat resumed meaningful work, including tool calls and delegated work. The goal card continued to show Goal stalled. During resumed work, get_goal still returned:

   {
     "status": "blocked",
     "updatedAt": 1791624649
   }

   That timestamp is 2026-10-10 09:30:49 UTC. A screenshot confirms the stalled card; the screenshot and full transcript are not attached because they contain private project context.

   Observed sequence:

   1. An existing goal was in the blocked/stalled state.
   2. The user explicitly requested resumption.
   3. Work toward that goal continued in the same chat.
   4. Both the visible goal card and the goal record remained blocked/stalled.

   Expected: when an explicit resume request is acted upon and work toward the goal resumes, reconcile the persisted goal state and UI to active/running. A blocked/stalled state should remain only while the blocking condition persists; an explicit user pause or exhausted budget should still be respected.

   Impact: the status misleadingly suggests work has stopped, making unattended execution and progress monitoring unreliable. This observation does not establish the underlying cause or whether automatic goal continuation was restored.

   Environment: Windows x64; read-only OS query returned Microsoft Windows NT 10.0.26200.0. Exact desktop build was not captured. No repository content, credentials, local paths, or private task identifiers are included.

   Follow-up observation (October 10, 2026): the user then explicitly said resume goal if you have not already. A get_goal call immediately afterward still returned status: "blocked" with the unchanged updatedAt: 1791624649, while deployment and schema-validation work toward the goal continued. This reproduces the mismatch after a second request that explicitly names the goal.

   👍React with 👍1Reacted by action-control