Windows Desktop: attaching a small PNG triggers WebSocket reconnect 5/5 in image-heavy compacted tasks

What version of the Codex App are you using (From “About Codex” dialog)?

26.903.71938

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Codex Desktop repeatedly loses the Responses WebSocket connection in specific image-heavy tasks.

Full error:

stream disconnected before completion: websocket closed by server before response.completed

The UI retries from Reconnecting 1/5 through Reconnecting 5/5, then may fall back to HTTP. The affected task becomes slow or appears stuck for minutes.

This appears to be task-history-specific rather than caused by the newly attached image itself:

• A 6,138-byte, 470x555 PNG triggered the failure in an image-heavy existing task.
• The exact same PNG succeeded in another task running in the same Codex process through the same proxy.
• Restarting Codex and reopening the affected task did not fix the problem.
• New tasks initially work normally and become affected after accumulating image/tool history and compaction.

Read-only diagnostics showed that historical inline images make the actual request much larger than the newly attached screenshot:

• Affected task 1: session file 92.83 MiB, 46 historical input_image entries, approximately 77.78 MiB of image-bearing history. The failing request was approximately 18.89 MB before compression.
• Affected task 2: session file 40.75 MiB, 19 historical images. The HTTP fallback request was approximately 38.28 MB before compression.
• Control task: the same image succeeded with no reconnects or HTTP fallback.

This is consistent with retained inline image payloads in compacted/replacement history, as described in #24550 and #36232. The exact network hop closing the WebSocket has not been proven.

What steps can reproduce the bug?

Feedback ID: 01a084f7-4d1d-7813-810e-c147f767437f

What is the expected behavior?

Attaching a small image should not make an existing task repeatedly lose its WebSocket connection.

Historical inline image payloads should be summarized, deduplicated, externalized, or otherwise bounded during compaction instead of being retransmitted indefinitely.

If the request exceeds a transport or payload limit, Codex should show a specific actionable error and recover promptly, rather than retrying the WebSocket five times and leaving the task slow or stuck.

Additional information

Environment:

• Codex Desktop App: 26.903.71938
• Platform: Microsoft Windows NT 10.0.19045.0 x64
• Windows system HTTP proxy: 127.0.0.1:38080
• Proxy implementation: local goproxy connected to a remote server over WebSocket

The proxy is a possible contributing transport variable, but it does not fully explain the task-specific behavior: the exact same small PNG succeeded in a control task running through the same Codex process and proxy, while only image-heavy existing tasks repeatedly disconnected.

The local and remote proxy processes did not crash or restart during the observed failures. A direct no-proxy comparison was not available because direct TLS connectivity from this machine is unreliable.

Related issues:

• https://github.com/openai/codex/issues/24550
• https://github.com/openai/codex/issues/36232
• https://github.com/openai/codex/issues/32868

Raw session files are not attached because they contain private prompts, local paths, tool output, and embedded image data. Redacted structural diagnostics can be provided if needed.

Start by tracing image-heavy task history through compaction or replacement history and the Responses WebSocket request path; the issue identifies retained inline images as the suspected trigger. Reproduce with an existing image-heavy task and compare it with the control task, then verify that historical image payloads are bounded and oversized requests recover with a specific error instead of repeated reconnects.