›_ Codex Issues
Codex Issues / #37647

[Windows App] Repeated `stream disconnected before completion` during long-running tool operations while work continues

Open 💬 3 comments Opened Aug 9, 2026 by klinkmedical
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

  • Client: Codex desktop app
  • OS: Windows
  • Model shown in UI: 5.6 Sol with Ultra reasoning
  • Observed: 2026-08-09, approximately 10:00–10:15 JST
  • App version: Not visible in the captured UI

Summary

The Codex desktop app repeatedly loses the response stream during a normal multi-step file/PDF operation. The error can occur several times in one task with different request IDs.

Importantly, the underlying tool work sometimes appears to continue after the error: the app later resumes output, additional commands run, and the task-progress/file-change indicators remain active. This suggests the backend/tool process may still be alive while the app-to-backend response stream is being lost or incorrectly surfaced as a fatal error.

This is not limited to one old conversation. A completely new thread initially completed the session-start protocol normally, but the same stream-disconnection problem returned once a longer PDF extraction/rendering and file-editing task began.

Error shown

stream disconnected before completion: An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID ... in your message.

The UI also displayed reconnect attempts such as:

Reconnecting 4/5
Reconnecting 3/5

Sequence observed

  1. An earlier thread had two interrupted turns following what appeared to be a false-positive interpretation of wording as a safety issue.
  2. Subsequent turns in that thread repeatedly showed stream disconnected before completion.
  3. A completely new Codex thread was created on the same machine and the session-start protocol completed successfully.
  4. A normal PDF test was started involving text extraction, cropping/rendering checks, command execution, image inspection, and file modifications.
  5. During that new-thread task, the stream disconnected repeatedly with different request IDs.
  6. Between disconnects, Codex resumed output and continued executing commands. The UI still showed task progress (3/6) and four modified files, indicating that the operation had not cleanly terminated when the stream error appeared.

Request IDs

04840085-ec25-4ee4-b370-aee2afd1a56b
16c96118-7c40-49db-aee9-b1f09e610d0a
f92d22c6-871d-4697-9983-442b07f9d00a
816e89ec-150e-411f-bf00-6bab796d93a6

Expected behavior

  • The response stream should remain connected for long-running tool/file operations.
  • If transport reconnects, the turn should recover without repeatedly surfacing a fatal-looking error while the backend continues working.
  • If a turn is stopped for a safety decision, the UI should distinguish that condition from a network/stream failure.

Actual behavior

  • Multiple stream-disconnection errors occur during one ordinary task.
  • Each failure receives a different request ID.
  • Reconnect attempts are shown, yet subsequent output and tool commands can still appear.
  • A new conversation does not reliably avoid the problem once the task becomes longer and tool-heavy.
  • This makes it difficult to know whether the operation is still running, partially completed, or safe to retry.

Privacy note

The screenshot and private project/repository names are intentionally not attached. The request IDs above are included so the corresponding backend events can be correlated.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 19 days ago

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

  • #36484
  • #36867

Powered by Codex Action

Sacas-git · 19 days ago

I’m experiencing the same issue repeatedly on the Codex Windows app today (August 9, 2026, JST).

The error is:

stream disconnected before completion: An error occurred while processing your request.

It has occurred multiple times during longer-running Codex operations.

Request IDs:

  • c7a49c45-2d8c-4b7f-badb-9709f4605bd7
  • c475f116-266c-4128-88bd-1665b592d92d
  • b42cca0e-af21-4101-8be4-d77229b30987
  • 22b1bb1f-4d7f-404b-a532-3b59f50a7c41
  • fd4bbbe0-d0d7-4a79-b02c-efd145b7cbb4
  • b86bbb59-7428-4751-b97b-db36a50023ba

This appears to be reproducible rather than a one-off network interruption.

In some cases, Codex appears to continue working after the error is displayed, so it may be related to the response stream disconnecting while the underlying task is still running.

Pluglug · 19 days ago

Independent Windows reproduction with logs and transport controls

I can reproduce the same issue repeatedly on August 9, 2026 JST.

Environment

  • Codex Windows App: 26.803.5235.0
  • Windows x64
  • Models/settings observed: gpt-5.6-sol, reasoning high through ultra
  • Service tiers: both priority (Fast) and default
  • Several unrelated mature threads failed sequentially; a source thread and its fork also both failed

Strongest reproduction

A thread that had previously been the healthy control ran normally for 5,023,133 ms (83m 43s), performing substantial reasoning and tool work, before failing:

  • Thread: 019fc338-6be9-7383-99b6-a07eb5e8fc31
  • Turn: 019fe434-22f4-7db2-8fe3-05ff78552c04
  • Final request ID: c3d42f4d-8f3f-4da8-ab55-392e1c4652a0
  • Final state: last_agent_message=null, codex_error_info=other

The client exhausted WebSocket retries 1/5 through 5/5, then fell back to HTTP Responses. The HTTP request was 5,281,562 bytes before zstd compression and 2,920,184 bytes after. The HTTP path received HTTP 200, then also exhausted retries through 5/5 and failed.

Retained HTTP retry request IDs:

  • 32b4846c-e0ac-4f09-8f57-62a61d9218c6
  • 84a2d033-58d8-45d1-99e8-87eb978e0392
  • d4df80c1-63a5-4587-b5dd-5c271734a65e
  • 6fa195e2-a545-468f-a44f-4713efe31a3b
  • final c3d42f4d-8f3f-4da8-ab55-392e1c4652a0

This makes a WebSocket-only failure or inability to establish basic HTTP connectivity insufficient explanations.

Cross-session / tier controls

A separate thread failed first under Fast and then failed again after switching to the Default tier. Both HTTP attempts received status 200 before the response stream disconnected:

  • Fast final request: 3f58c6af-f577-485b-9669-18c9bbc7fd1b
  • Default final request: 3b92edb3-d12c-4729-b406-5c027bf07a0e

During that Default-tier failure, the later-failing control thread above was still producing normal reasoning, tool calls, tool outputs, and patch application on the same PC, account, network, and App process. It then transitioned to the same failure pattern later. This weakens both a single poisoned-context explanation and a host-wide basic network outage explanation.

A strict codex doctor --json check during the incident passed provider HTTP reachability and the Responses WebSocket handshake. Context7 and Cloudflare MCP processes were absent from the App tree during the reproduction.

Local App state after failure

Immediately after the final failure, the full App process tree retained:

  • 60 processes
  • 5,638.7 MB aggregate working set
  • 5,775.8 MB aggregate private bytes
  • 1,196 threads
  • 17,922 handles
  • 91 TCP endpoints
  • 25 CLOSE_WAIT sockets
  • 18 node.exe and 17 node_repl.exe processes

This is elevated, but below an earlier retained-resource snapshot, so reaching the previous resource maximum is not required for the stream failure.

Uploaded feedback

Fresh logs and diagnostics for the formerly healthy control failure were uploaded through the built-in feedback flow:

  • 019fe484-1541-70f2-87fe-f39693e362db

Related Default-tier reproduction with logs:

  • 019fe45f-f5ed-7610-98b9-76468088dabd

Prompt bodies, tool payloads, private source code, authorization headers, cookies, and credentials are intentionally omitted here. Please correlate the request IDs and feedback threads with server-side traces.