Codex Desktop automatically marks Goal blocked after transient gpt-5.6-sol capacity errors without an update_goal call #41808

Codex App version

Codex Framework 151.0.7922.174; Codex runtime 0.151.0-alpha.7.1

Subscription

Pro

Platform

Darwin 25.5.0 arm64 arm

Summary

A long-running Codex Desktop Goal was automatically changed to blocked after transient model-capacity errors:

Selected model is at capacity. Please try a different model.

The user did not pause the Goal, and the agent did not call update_goal(status="blocked").

Observed state transition

A redacted local timeline from 2026-08-31:

2026-08-31 07:50:55Z | WebSocket disconnect | retrying sampling request (1/5 in 200ms)
2026-08-31 07:51:40Z | gpt-5.6-sol | medium | Selected model is at capacity
2026-08-31 07:51:40Z | Goal database status changed to blocked
2026-08-31 07:51:50Z | gpt-5.6-sol | medium | Selected model is at capacity
2026-08-31 07:53:14Z | gpt-5.6-sol | medium | Selected model is at capacity

A strict search found zero actual tool_name="update_goal" calls in the relevant window. The only loose text match came from tool/context documentation, not a tool invocation.

The task had already completed tools and made progress. Later continuation turns still executed after the persisted Goal status became blocked, leaving the scheduler, persisted Goal state, and UI inconsistent.

The same logs report:

• full_context_window_limit_reached=false
• token_limit_reached=false

This was therefore not a context-window or Goal token-budget stop.

Reproduction

1. Start a long-running Goal in Codex Desktop.
2. Use gpt-5.6-sol with medium reasoning.
3. Let the Goal continue across multiple turns and execute tools.
4. Encounter repeated transient Selected model is at capacity responses.
5. Observe that ordinary WebSocket disconnects use the existing bounded retry path, while capacity errors terminate the turn without that retry path.
6. After repeated capacity errors, inspect or resume the Goal.
7. Observe that the Goal is persisted or displayed as blocked even though:
   • the user did not pause it,
   • the agent did not call update_goal(blocked),
   • later continuation turns can still execute.

The capacity response is backend-dependent and cannot be triggered deterministically.

Expected behavior

A transient model-capacity error should be classified as retryable and should not automatically convert an active Goal to blocked.

• Retry with bounded exponential backoff.
• Preserve completed tool results and accepted input.
• If the retry budget is exhausted, enter a retained-state waiting or paused state with explicit retry controls.
• Transition back to active when continuation resumes.
• Reserve blocked for a genuine task impasse or an explicit supported state transition.

Related issues

• Retry transient capacity errors with backoff and retained task state #22390 — transient capacity errors should retry and retain task state
• Goal mode can enter a one-way blocked state after a recoverable failure #36249 — Goal can enter a one-way blocked state after recoverable failure
• Blocked goal does not transition back to active when user resumes and agent continues work #29370 — blocked Goal may remain blocked while resumed work runs
• Codex Desktop emits “remote compact task” model-capacity error during automatic compaction #35911 — gpt-5.6-sol + medium capacity error during compaction

This report adds a current Codex Desktop observation where the Goal database timestamp matches the capacity failure and no actual update_goal(blocked) call occurred.

Raw logs are intentionally not attached because they contain task content, thread IDs, local paths, tool arguments, and routing or authentication metadata. The timeline above is the redacted minimal evidence.