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

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

   contextIssues related to context management (including compaction)Issues related to context management (including compaction)

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

   on Jul 18, 2026
2. github-actions commented on Jul 18, 2026

   

   github-actionsbot

   on Jul 18, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Unexpected “Request Blocked” error during authorized regression-fixing task #33103
   • Auto-compaction uses stale token usage after tool output, causing unrecoverable context overflow #32888

   Powered by Codex Action
3. PeiWeiChi commented on Jul 19, 2026

   

   PeiWeiChi

   on Jul 19, 2026

   More actions

   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.
4. PeiWeiChi commented on Jul 19, 2026

   

   PeiWeiChi

   on Jul 19, 2026

   More actions

   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.
   2. 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.
   3. 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.
   4. 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.
5. carbunklet commented on Jul 22, 2026

   

   carbunklet

   on Jul 22, 2026

   More actions

   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
   

   5. Two later neutral follow-ups (Oi parou por que? and ?) failed after approximately three seconds with the same error and no assistant response.
   6. A same-directory fork containing the completed history also entered systemError immediately on its first recovery prompt.
   7. 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.
6. hendrykcosta75 commented on Jul 23, 2026

   

   hendrykcosta75

   on Jul 23, 2026

   More actions

   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: CLI: Error running remote compact task: Request blocked #35001

   Happy to provide more logs if needed.
7. HayasakaInori commented on Jul 26, 2026

   

   HayasakaInori

   on Jul 26, 2026 – with ChatGPT Codex Connector

   More actions

   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.