Repository navigation
Windows Desktop: attaching a small PNG triggers WebSocket reconnect 5/5 in image-heavy compacted tasks #44715
Description
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_imageentries, 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:
- Responses WebSocket falls back when compacted replacement_history contains large inline images #24550
- Current Windows Desktop still fails remote compaction for image-heavy long-running tasks (reconnect 5/5) #36232
- WebSocket disconnects before response.completed after viewing multiple images in a long Codex CLI turn #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.
Activity
github-actions commentedon Sep 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
rightevil commentedon Sep 11, 2026
after reconnect 5/5,it will turn to https, it's pretty slow. maybe 1 hour for a work(it only take 10-20 mins in websocket).
BenjaminNH commentedon Sep 25, 2026
Reproduction on Windows, Codex Desktop 26.917.9434.0.
I can reproduce this in a new conversation:
After the model switch, the thread shows Reconnecting and saturates upload. A new thread with no images, or the same thread before the model switch, does not do this. On the same machine and network, a 30-second sample while following up in the affected thread reached about 104 Mbps average and 197 Mbps peak (about 390 MB sent). Idle on that machine was 0 Mbps.
This looks like a model switch invalidating the prompt cache and forcing the full context, including inline images, to be uploaded again. The Reconnecting 1/5–5/5 retries then send that payload repeatedly.
dz3211 commentedon Sep 29, 2026
Additional Windows reproduction: large repeated uploads after successful WebSocket handshakes
Codex Desktop 26.924.22138 (production), Windows package 26.924.2738.0, bundled app-server 0.158.0-alpha.2.1.
In an image-heavy task, the client successfully established WebSocket connections and negotiated
permessage-deflate. After a full application restart, the task nevertheless retried 1/5 through 5/5 with:Measured impact:
Request compression and the retained-image compaction budget were already enabled. Successful handshakes and negotiated compression were insufficient to prevent the recurrence. The affected task was stopped to prevent further transfers.
The logs did not preserve the WebSocket close code; neither an exact message-size threshold nor the component closing the connection is established. This is a reproduction report, not a claim that every disconnection has the same cause.
Please investigate aggregate serialized image-history size, preserve close codes/reasons, avoid repeated unchanged requests after unrecoverable failures, and provide bounded recovery from HTTP fallback to incremental transmission for existing tasks.
Related: #23665 and #43015.
This report contains only software versions, error strings, and aggregate traffic measurements. No raw logs, chat content, screenshots, account credentials, task IDs, personal paths, or proxy-provider/node details are included.
Follow-up: native compaction reduced the payload, but fresh-process WebSocket recovery still failed
Native compaction completed in the same conversation. Three subsequent fixed-text checks completed with no tool calls. Their HTTP request bodies after compression were 845,284, 846,879, and 846,996 bytes.
The third check was performed after a confirmed full application restart, with the existing proxy configuration unchanged. It again encountered
tls handshake eofduring new WebSocket connection attempts, thenfalling back to HTTP. That final HTTP request was 1,245,347 bytes before compression / 846,996 bytes after compression and completed successfully.This confirms substantial payload reduction, not restored incremental transport. The new TLS-handshake failure occurs before sending the reduced image-bearing request and must be distinguished from the earlier successful-handshake-then-close failure. Compaction and restart alone did not resolve the complete problem. Testing was stopped after these three checks.
xiao-do-do commentedon Oct 2, 2026
Additional affected macOS user: the reconnect 5/5 -> HTTP/SSE fallback -> repeated large uploads sequence described here also severely disrupts my multi-round image-generation workflow.
I am also affected on macOS while iterating on image generation across multiple turns. After reconnect attempts reach 5/5, the transport falls back to HTTP/SSE. Continuing the same conversation then causes repeated large image uploads, heavy bandwidth use, and substantial delays between turns. This severely affects Codex conversation efficiency and makes iterative design work difficult, including ordinary follow-up messages after image generation.
Please correlate this with #38846 (WebSocket close code 1009 / message too big), #24550 (large inline-image history causing WebSocket fallback), and #23665 (recovery from HTTP fallback). A 1009 close and the subsequent HTTP/SSE fallback are different stages of the failure: an oversized WebSocket message can trigger the disconnect, and fallback can then expose the repeated full-history upload cost. I have not captured the close code from my own session, so I am reporting the retry/fallback and bandwidth symptoms rather than claiming a confirmed 1009 reproduction.
Please prioritize a supported recovery path that preserves the text conversation and current design state. Retrying the same oversized history repeatedly does not restore a usable conversation. Byte-aware request checks, bounded historical-image handling, and a controlled return to incremental transport would directly address this impact.
xiao-do-do commentedon Oct 2, 2026
over 100 GB of data usage in a single day
While using Codex for multi-round image generation, my daily data usage exceeded 100 GB. After reconnect attempts reach 5/5 and the connection falls back to HTTP/SSE, continuing the conversation appears to repeatedly upload the accumulated image history—even for ordinary text follow-ups.
This severely affects conversation efficiency and design iteration. The impact includes excessive data consumption, sustained bandwidth use, and long waits between turns.
Please prioritize investigating the relationship between oversized image history, WebSocket 1009 errors, transport fallback, and repeated full-history uploads. A supported recovery method that preserves the text conversation while removing unnecessary historical image payloads is urgently needed.
xiao-do-do commentedon Oct 2, 2026
This is a serious performance and usability issue. Repeated uploads of historical images make Codex respond extremely slowly, even to simple text follow-ups. Combined with over 100 GB of daily data usage, this severely disrupts normal conversation and design iteration. Please prioritize investigating and fixing this problem.