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

Open 💬 1 comment Opened Jun 21, 2026 by johnsilvavlogs

Summary

A Codex Desktop goal that has been marked blocked can remain visually and programmatically blocked after the user resolves the blocker and explicitly asks the agent to resume. The agent can continue executing work, but the UI footer still shows Goal blocked ... and the Resume goal control while the turn is already running.

This makes it look like the agent is not able to resume goals by itself, and there does not appear to be an agent-visible status transition from blocked back to active/in-progress.

Observed behavior

In a Codex Desktop thread, the user resolved a blocker and sent:

done just quit. proceed. resume goal

The agent then resumed work and performed the expected actions:

  • removed the waiting marker from the thread title
  • re-checked external state
  • ran the guarded recovery command
  • continued toward verification

However the goal footer still displayed:

Goal blocked Diagnose and fix why John's 100-hour Slay the Spire 2...

and the UI still showed the Resume goal button/tooltip while the agent was actively working. A screenshot taken during the active turn showed Working for 43s, active assistant status text, command execution rows, and the bottom goal strip still saying Goal blocked with Resume goal visible.

During the resumed turn, the agent also observed via the goal tool that the goal record still had status: blocked before continuing. There was no obvious tool/API path for the agent to mark the goal as active/resumed; the exposed transitions appeared to support terminal statuses such as complete/blocked, but not unblocking.

Expected behavior

When a blocked goal is resumed by the user, either:

  1. the goal should automatically transition from blocked to an active/running state as soon as the resumed turn starts, or
  2. the agent should have a supported tool/API transition to mark the goal unblocked/resumed before continuing.

The UI footer should no longer show Goal blocked or a Resume goal button while an active resumed turn is already running for that same goal.

Actual behavior

The resumed turn runs, but the goal remains displayed as blocked. The UI simultaneously shows active work and a blocked goal state.

Impact

  • Users cannot tell whether the goal is actually resumed or still blocked.
  • The agent appears unable to recover goal state by itself after the user resolves the blocker.
  • This can cause repeated manual resume attempts and confusing side conversations while the original turn is actually progressing.
  • It weakens the blocked/resume contract for long-running goal workflows.

Reproduction outline

  1. Start a Codex Desktop goal.
  2. Have the agent mark the goal blocked due to a real external blocker.
  3. Resolve the external blocker.
  4. Send a user message such as done, proceed, resume goal.
  5. Observe that the agent starts working again.
  6. Observe that the bottom goal strip can still show Goal blocked ... and Resume goal during the active resumed turn.

Nearby issues checked

I searched for obvious duplicates and found nearby but not exact issues:

  • #28144: wait/wake support for goals without spending tokens
  • #28177: Goal blocked after auto compact fail
  • #26784: renderer crash when opening a blocked-goal thread

This report is specifically about a user-resolved blocked goal continuing to display/remain blocked while the agent is already executing the resumed turn.

Environment

  • Product: Codex Desktop
  • Platform: macOS
  • Date observed: 2026-06-21
  • Screenshot evidence: local screenshot captured from the Codex UI showing active work plus the still-blocked goal footer/Resume goal control.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗