Long Codex task becomes permanently "Request blocked" after successful completion

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

• #33103
• #32888

Powered by Codex Action

Additional reproduction from Codex Desktop 26.715.31925 (bundled CLI
0.145.0-alpha.18) on macOS 26.5.2:

• In-product /feedback recorded the sanitized report with no logs attached:

019f7c95-e3a7-7822-9ef0-57db2b259f5a.

• A fresh post-update UI thread completed six turns, then its seventh turn failed

after 5.998 seconds with Request blocked, no time-to-first-token, and
codex_error_info: other.

• Last successful usage was 190,146 / 258,400 context tokens.
• The fresh thread made zero local /v1/chat/completions calls. A separate,

synthetic local-MLX control returned HTTP 200 and LOCAL_LLM_OK.

• Codex CLI continues to work under the same account and model.

Affected UI thread IDs:

• 019f7476-0149-7d30-8316-c0522a2b9ec8
• 019f79af-d26c-7920-be59-9849ebf349d4

This adds a second fresh-thread recurrence and rules out local LLM execution as
a required trigger. Broad logs were not uploaded because they may contain
protected patient data.

Correction/addendum after a structured cross-model review of my sanitized
diagnostic (wf_290c1c9e-071; Claude and Codex finding, Gemini/Codex/GLM
verification; 27 agents, 0 agent errors). No logs, prompt bodies, project data,
or patient data were provided to the review.

The review identified four places where my earlier interpretation was too
strong:

1. Context exhaustion is not ruled out. The reported 190,146 / 258,400 tokens

came from the last successful request, not the failing assembled request.

1. The successful CLI control is unmatched for context depth, turn count, and

tool history. It shows continued CLI operability, but does not causally
isolate a Desktop-only request path.

1. The earlier incident retained an upstream invalid_prompt SSE payload. For

the latest recurrence, I confirmed only the UI Request blocked message and
codex_error_info: other; its exact upstream subtype is not established.

1. The latest affected thread made no direct local /v1/chat/completions

request. This shows that a direct local completion is not a necessary trigger,
but it does not exclude sandbox denials, permission escalations, or approval
artifacts embedded in accumulated tool history.

The provisional hypothesis ranking is now:

1. Accumulated thread-history reconstruction or compaction.
2. Upstream validation of the reconstructed long-history payload.
3. Sandbox/permission/approval artifacts embedded in tool history.
4. Transient websocket metadata, currently less supported because affected

threads remain blocked on retry.

The most useful next evidence would be the failing request's assembled input
tokens and context limit; stable request/error/correlation IDs; and a UI-versus-
CLI comparison matched on sanitized history, context depth, turn count, and tool
artifacts. A fresh thread seeded with the blocked history would also distinguish
fresh-thread recovery from history-specific failure, if such replay is feasible
internally.

Additional Windows reproduction with a same-directory fork control.

Environment:

• Codex Desktop / bundled CLI: 0.145.0-alpha.30
• Platform: Windows
• Authentication: ChatGPT OAuth
• Model: gpt-5.6-sol, high reasoning
• Original affected thread: 019f8a6e-f23c-7643-90dc-9d69e2c88d95
• Same-directory fork that inherited the failure: 019f8ab1-7f20-7d93-b409-2560eb896fa0
• Fresh replacement task that works: 019f8ab2-c349-78a1-bcf7-c4256ddf09ef

Observed sequence on 2026-07-22:

1. A long benign coding/evaluation turn had been working normally.
2. At 16:23:22Z, the response stream disconnected and the client retried.
3. The WebSocket reconnected successfully; authentication remained attached and GET /backend-api/codex/models returned 200 OK.
4. The retried request emitted response.in_progress, followed at 16:23:27Z by an error event and:

Request blocked.
codex_error_info: other

1. Two later neutral follow-ups (Oi parou por que? and ?) failed after approximately three seconds with the same error and no assistant response.
2. A same-directory fork containing the completed history also entered systemError immediately on its first recovery prompt.
3. A completely fresh task, instructed to use the exact same existing worktree and repository state without copying the affected history, started and continued normally.

Relevant diagnostics from the last successful request:

• Input usage: 105,680 / 258,400 context tokens.
• Account rate-limit usage: 33%; no rate-limit-reached state.
• Authentication and model discovery were healthy.
• The exact local Cloudflare credential values used by the project were checked and were not present in the session transcript.
• The literal marker <|channel|>analysis does not occur in the affected rollout transcript.
• No attachment was added to the failing turn.

This reproduction strongly isolates the failure to reconstructed thread/history state rather than the account, repository, worktree, authentication, rate limit, or the user's short follow-up text. The stream disconnect/retry immediately preceding the first block may be relevant, although the client-visible error category remains only other.

Same symptoms here, explicitly during remote compaction:

Error running remote compact task: Request blocked.

• Uploaded thread ID: 019f904e-792e-7ff2-92ef-ea66603eced0
• Duplicate of this issue: #35001

Happy to provide more logs if needed.

Confirming the same persistent poisoned-thread failure on Codex Desktop for macOS, with an additional multi-agent/tool-return trigger and a fork that inherited the failure.

Environment

• Codex Desktop build: 26.721.41059
• Bundled CLI observed during feedback: 0.146.0-alpha.3.1
• Subscription: Pro
• Model: gpt-5.6-sol
• Affected thread: 019f9981-39b3-76e3-b125-744bb600be7e

Timeline and diagnostics

The first failing turn was 019f9dd5-1c1a-7dc0-905b-3ed48260ad89 on 2026-07-26 17:50–17:53 CST. It ran normally for 219 seconds: reasoning and commentary were emitted, six batches of web searches completed, and three existing subagent threads returned research results. Immediately after the final subagent result arrived, the root turn ended without a final assistant message:

{
  "type": "task_complete",
  "turn_id": "019f9dd5-1c1a-7dc0-905b-3ed48260ad89",
  "last_agent_message": null,
  "error": {
    "message": "Request blocked.",
    "codex_error_info": "other"
  }
}

The last recorded model request used 170082 input tokens with a 258400-token context window. Rate-limit usage was 2%, with no rate limit reached.

A later benign two-word Chinese prompt meaning “what happened” (019f9ddd-b0f9-70d1-a15f-8ae126b8c678) failed after 10 seconds with the identical error and no assistant output. At the start of that recovery turn, queued subagent messages were appended, but inference never produced a reply.

Forking the affected task also inherited the unusable state: fork 019f9dde-3180-7dd0-a7fb-631a29dc8643 reports systemError and rejects a benign follow-up. Other fresh tasks continue to work.

This strengthens the hypothesis that a large serialized context plus queued tool/subagent payload can permanently poison a thread, and that a normal fork copies the poisoned state. The nominal model context limit was not exceeded.

Expected behavior

• Compact or drop safely replayable tool/subagent payloads before the request becomes invalid.
• Return a specific recoverable context/payload error instead of the generic Request blocked.
• Permit later benign turns to continue.
• Ensure a fork can start from a valid compacted state rather than inheriting the permanent failure.

A private /feedback report was also recorded as 019f9dea-313f-7bf1-bd3c-db222c054e53. Full logs were not uploaded because they contain private workspace content.