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

Start by tracing the Windows app's response-stream reconnect handling for long-running tool operations, using the reported sequence and request IDs as correlation points. Compare the stream lifecycle with continued command execution and determine what tests cover disconnects, reconnects, and turn status; done means the UI accurately reflects recovery or termination without misleading fatal errors.

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.