Goal mode can enter a one-way blocked state after a recoverable failure

[7ammad]

Environment

• Codex Desktop on Windows
• Goal mode

Problem

A long-running goal can be marked blocked after one recoverable subtask failure even though other executable work and an alternate route remain. When the user explicitly tells Codex to continue, the UI can keep showing Goal blocked.

The model-facing goal tool exposes terminal transitions to complete or blocked, but no corresponding active or resume transition. This makes an incorrect blocked decision effectively one-way.

Root reasoning failure

The deeper defect is not only the missing resume control. Codex can reason about blocking at the wrong level:

1. A child branch encounters an unavailable external dependency.
2. Codex promotes that branch condition into a blocker for the entire parent goal.
3. It does not test whether the external dependency is actually on the parent goal’s critical path.
4. It does not inventory unfinished work that is independent of that dependency.
5. It marks the goal blocked while directly executable build work remains incomplete.

In other words, the runtime accepts a global terminal claim without requiring evidence that the whole outcome—not merely one route—is blocked.

Reproduction

1. Start a long-running goal and instruct Codex to continue autonomously until the outcome is achieved.
2. During execution, make one route fail recoverably, such as an expired session or rejected authentication method, while an alternate route and independent build work remain available.
3. Observe that the model can mark the parent goal blocked without completing or accounting for the independent work.
4. Explicitly tell Codex to continue through the alternate route.
5. Observe that the goal may remain displayed as blocked with no model tool for restoring it to active.

Actual behavior

• A recoverable child-branch failure can terminate the parent goal as blocked.
• An external dependency can be treated as globally load-bearing without a critical-path check.
• Independent unfinished work is not necessarily enumerated before the terminal transition.
• The transition can occur while executable work remains.
• Explicit user continuation does not reliably restore the active state.
• The model has no resume/active status transition.

Expected behavior

Before accepting blocked, Goal mode should require a parent-level pre-block decision test:

1. Define the exact dependency: What external fact, authority, credential, or state change is unavailable?
2. Map it to acceptance: Which parent acceptance condition cannot be met without it?
3. Critical-path test: Is it truly required now, or can an alternate route satisfy the same condition?
4. Remaining-work inventory: What executable branches remain independent of it?
5. Exhaustion evidence: Which materially distinct authorized routes were attempted, and why did each fail?
6. Scope the block: If only one branch is affected, record a branch-level deferred dependency and continue the parent.
7. Explain the transition: Show the user why the entire goal, rather than one subtask, is blocked.

blocked should be accepted only when the parent goal is genuinely at an impasse and no materially distinct executable route remains.

Suggested product changes:

1. Enforce the documented repeated-blocker threshold before accepting blocked.
2. Reject blocked when the current state contains executable branches, alternate routes, or unfinished independent work.
3. Require structured fields for dependency, blocked_acceptance_condition, remaining_executable_work, routes_exhausted, and required_external_change.
4. Add a first-class active/resume transition triggered by explicit user continuation.
5. Add a user preference: Never let Codex auto-block goals. In that mode, only the user can pause or cancel; Codex records dependencies and continues other work.
6. Represent recoverable blockers as branch-level deferred dependencies rather than terminating the parent goal.
7. Display the exact blocking reason, critical-path justification, and required external action.

Impact

Autonomous work stops prematurely, executable building is abandoned, users must babysit continuation, the UI reports a false terminal state, and recovery is unclear.

Related but distinct

Issue #28923 concerns goals spinning during future-time waits. This report concerns the inverse failure: goals terminate as blocked too early, due to incorrect parent-versus-branch reasoning, and then lack a reliable resume transition.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex Desktop marks a goal blocked while explicit approval is pending in a Full access session #35235
• gpt-5.6-sol “Request blocked” permanently poisons a long-running /goal thread #35160

Powered by Codex Action