Repository navigation
Bug: image-heavy chats repeatedly reconnect and become very slow #20805
Description
Summary
When a Codex App chat accumulates many attached images over the course of a conversation, the app starts reconnecting on nearly every new prompt/steer/follow-up and the thread becomes extremely slow.
What version of the Codex App are you using (From “About Codex” dialog)?
26.429.30905
What subscription do you have?
Plus
What platform is your computer?
Darwin 25.3.0 arm64 arm
macOS
What issue are you seeing?
When a chat accumulates many attached images over the course of a conversation, the Codex app eventually starts showing Reconnecting... on almost every interaction: new prompts, steering messages, follow-ups, etc.
This is not necessarily caused by attaching many images in a single prompt. In my case, it happens after a longer workflow where images are gradually added across the conversation: several screenshots in one prompt, another image later, more UI iteration screenshots after that, and so on.
Once the chat reaches that state, each new interaction often goes through multiple reconnect attempts, usually up to 5/5. After the retries finish, the run may continue, but the chat becomes extremely slow.
This has been happening consistently for roughly the last 10 days, around late April / early May 2026.
Common cases where I hit this:
- Browser/sidebar annotation runs that attach many images during the work
- UI iteration workflows with many screenshots across multiple prompts
- Longer chats where images accumulate gradually over time
What steps can reproduce the bug?
- Start a Codex App chat.
- Work through a longer image-heavy flow.
- Attach images gradually across the conversation, not necessarily all in one prompt.
- Example: several screenshots in one prompt, another screenshot later, then more UI iteration screenshots in follow-up prompts.
- Continue sending prompts, steering messages, or follow-ups after the thread has accumulated many attached images.
- Observe repeated
Reconnecting...messages, often reaching5/5. - After the reconnect cycle completes, the chat may continue, but interactions become extremely slow.
What is the expected behavior?
Image-heavy chats should remain responsive across the conversation, or degrade gracefully without repeated reconnect cycles on every new interaction.
The app should not repeatedly go through Reconnecting... 2/5, 3/5, 4/5, 5/5 after a thread has accumulated many images.
Additional information
The attached screenshot shows the repeated reconnect messages during a run.
This seems related to accumulated conversation state / attachments over time rather than a one-off network disconnect, because once a chat reaches this state the reconnect behavior tends to repeat on subsequent prompts in the same thread.
Activity
github-actions commentedon May 2, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Keesan12 commentedon May 18, 2026
This feels like attachment accretion is being treated as normal context growth until transport starts flapping.
The fix probably is not bigger retries. The runtime likely needs an attachment-aware health receipt before each turn: attachment count or weight, reconnect streak, and a threshold where the thread stops accepting more images without a compact-or-summarize step. Otherwise the reconnect loop just hides that the thread is already in a degraded state.
If you end up adding that kind of receipt layer, I would love to compare it against the same boundary we are handling in MartinLoop, because "responsive chat" versus "attachment-heavy evidence log" feels like the real seam here.
anngrrr commentedon May 25, 2026
I may have found an important pattern related to the Windows freezing/reconnect issue.
In my case, the problem became severe specifically in a long Codex thread containing many image attachments (multimodal workflow). I was frequently using screenshots/images to explain tasks to Codex.
Symptoms:
The issue did NOT start immediately after updating the app. The update happened earlier, while the severe freezing started later, which makes me suspect a server-side rollout / feature flag interaction.
My suspicion is that reconnect/recovery logic may be struggling with large multimodal thread hydration/restoration on Windows.
Keesan12 commentedon May 25, 2026
That pattern makes the seam clearer: this is probably less about generic Windows slowness and more about long-lived multimodal thread hydration crossing a practical threshold without any operator-visible warning.
If the team adds a health receipt here, I would make it explicit before send rather than only after reconnect starts:
That would give users a readable boundary instead of a mystery slowdown. If you end up testing that kind of threshold, I would genuinely love to compare notes, because this is very close to the same "evidence log versus active working context" boundary we keep hitting in MartinLoop.
vyctorbrzezowski commentedon Jun 5, 2026
This is still relevant. So far, been using this skill to counter it:
https://clawhub.ai/vyctorbrzezowski/codex-session-image-scrubber
It cleans images/base64 from the session and keeps context, telemetry, etc. Chat becomes much lighter and responsive agian.
YurySolovyov commentedon Jun 5, 2026
FWIW, I've been telling codex to draw some programmatic art in python as placeholder and then in separate session replace it with something real from Image Gen as workaround.
Bangeanix commentedon Jun 18, 2026
This worked beautifully for me!! Thanks a ton! 😃
iamtornado commentedon Aug 23, 2026
Adding a current Windows Desktop corroboration, with generated images rather than only manually attached screenshots.
Environment:
0.149.0-alpha.4.1Sanitized local evidence:
79,070,850bytes (~75.41 MiB).21,968,314bytes (~20.95 MiB).data:imageURIs (28 unique payloads), accounting for approximately 43.86 MiB of Base64 text.1/5through5/5over about nine minutes and then loggedfalling back to HTTP.1/5-to-5/5sequence and HTTP fallback.Connection closed normally,websocket closed by server before response.completed, and Windowsos error 10054.This confirms that the visible
Reconnecting...state was backed by actual response-stream retries and HTTP fallback, not only UI sluggishness. This is not a packet capture, so I cannot claim that the entire rollout was transmitted on every turn or that image bytes alone are the proven root cause. However, the timing and persisted-history growth are strongly consistent with this report.Related reports such as #33760 and #24550 suggest generated-image/history payload growth as a possible mechanism. Please prioritize investigation into whether historical inline image payloads are retained or re-serialized into subsequent requests, and whether Desktop can deduplicate, externalize, or compact them before transport. This issue makes longer image-generation workflows increasingly difficult to continue.
Privacy note: I am not uploading the raw rollout, logs, images, local paths, task ID, or conversation content because they contain private data.
Lyt-May commentedon Aug 30, 2026
Codex desktop 26.825.32147 (build 7303), bundled CLI 0.146.0-alpha.3.1, macOS 26.5.2 arm64.
Image-heavy UI iteration tasks repeatedly enter “Reconnecting”. A turn referencing four images produced a 7,887,884-byte JSONL record; another with eight assets produced a 12,924,451-byte record. In one occurrence, the last tool output completed at 16:55:05, the task aborted at 16:58:21, the worker exited at 16:58:27, and a new worker started at 16:58:36. Continuing the task then remained at
task_started. Narrow unified-log inspection showed no explicit WebSocket, network, crash, or memory error.Expected: image data stored out of line or deduplicated, bounded parallel image payloads, and a clear resumable error when a worker is replaced.
Privacy: raw transcripts, images, project name, username, local paths, and task IDs are omitted.
NeverMissYou12 commentedon Sep 28, 2026
Independent macOS reproduction on 2026-09-28: measured persistent slowdown after HTTP fallback
I am adding a newer reproduction and local diagnostic evidence to this existing issue. The same user-visible pattern still occurs on desktop build 26.924.22138.
Summary
After Codex reaches reconnect 5/5 and resumes, subsequent steps remain much slower. Local logs show WebSocket failures followed by HTTP fallback. In affected sessions, later HTTP requests repeatedly prepare large compressed full-context bodies. The matching source version keeps the fallback active for the runtime session.
This is a reproducible user-observed regression pattern, not a fully isolated root-cause claim. Please investigate transport recovery, large-context request reuse, and any additional usage from retries or incomplete responses.
Environment
model_context_window = 1000000; the affected live turn reports an effective window of 828400 tokensReproduction pattern
The interruption was observed naturally, not deliberately injected. These steps describe the observed pattern; they are not a guaranteed deterministic reproduction on another network.
Live reproduction on 2026-09-28
All timestamps in this table are UTC.
falling back to HTTPThread:
01a0e18e-d877-77e2-9786-7ba94e7258e3Turn:
01a0e8a7-6f9c-7ce0-880a-a9d4131955f0The stream errors include normal connection closure, Broken pipe, and closure before response.completed. Message/tool activity resumed. The short live snapshot establishes the retry/fallback/repeated-request sequence; the longer-duration slowdown evidence comes from the historical cases below.
Historical measurements
Presentation thread:
01a0df21-2db3-77b3-bd14-14ec98c8579aSummary-document turn:
01a0e218-acf9-7c80-ba86-e876d53d3b2bShort-reply turn:
01a0e250-9a36-73a1-afda-a7c8ccd68267Map-building turn:
01a0e209-d6ac-7221-85c0-1852b21dd8f6Token usage clarification
The presentation parent chat records 55 unique model response IDs and 9,225,334 total tokens: 8,265,088 cached input + 922,382 uncached input + 37,864 output. Reasoning tokens are already included in output. This total includes the initial presentation, revision, subsequent summary document, and short reply, rather than the initial presentation alone. Child-agent usage is excluded from this number.
Per-response increments match the final cumulative total; cumulative snapshots were not repeatedly summed. Repeated logical input accounting can also occur with WebSocket incremental transport. Therefore the entire token total should not be attributed to HTTP fallback, and it does not establish double billing or subscription usage weights. Please audit server-side usage for failed/retried requests separately.
Matching source and suspected mechanism
Bundled version matches tag
rust-v0.158.0-alpha.2.1, commit0d9c7cbfa6cf1489f55a8a9542b75ddd2c061807.Expected behavior: recovery should avoid leaving every subsequent small step subject to repeated large full-context requests where reuse/recovery is feasible, or clearly surface the degraded transport and a recovery path.
Measurement limits
Request and supporting evidence
Please correlate the identified turns with server-side traces, investigate recovery from session-scoped HTTP fallback and full-context requests, and audit incomplete/retried-response usage. Related measured image-upload behavior is reported in #45109; I have not established that every case has the same root cause.
Selected sanitized evidence is included below; the full sanitized bundle can be provided on request. No ZIP is attached to this comment. The original screenshot is also omitted because it contains unrelated sidebar chat titles.
Selected sanitized evidence (inline)
The following are normalized records extracted from the local logs and session usage events; chat bodies, credentials, and private file paths are omitted. All timestamps are UTC.
Live reproduction thread:
01a0e18e-d877-77e2-9786-7ba94e7258e3Turn:
01a0e8a7-6f9c-7ce0-880a-a9d4131955f0{"db_id":17179028,"utc":"2026-09-28T15:35:42.536+00:00","detail":"stream disconnected - retrying sampling request (5/5 in 3.5s)... turn_id=01a0e8a7-6f9c-7ce0-880a-a9d4131955f0 retries=5 max_retries=5 sampling_error=stream disconnected before completion: IO error: Broken pipe (os error 32)","event":"retry"} {"db_id":17179186,"utc":"2026-09-28T15:35:51.264+00:00","detail":"falling back to HTTP","event":"client_event"} {"db_id":17179194,"utc":"2026-09-28T15:35:51.342+00:00","pre_compression_bytes":26200543,"post_compression_bytes":19100619,"compression_duration_ms":34,"event":"HTTP_compressed_body"} {"db_id":17179371,"utc":"2026-09-28T15:36:29.762+00:00","status":"200","event":"HTTP_response_headers"} {"db_id":17179500,"utc":"2026-09-28T15:36:49.884+00:00","pre_compression_bytes":26202871,"post_compression_bytes":19102745,"compression_duration_ms":29,"event":"HTTP_compressed_body"} {"db_id":17179689,"utc":"2026-09-28T15:37:23.263+00:00","status":"200","event":"HTTP_response_headers"}A later short reply in the presentation chat also prepared a 53.54 MiB compressed body, with no local tool calls and ~84.55 s from compression to response headers.
Thread:
01a0df21-2db3-77b3-bd14-14ec98c8579aTurn:
01a0e250-9a36-73a1-afda-a7c8ccd68267{"db_id":17158234,"utc":"2026-09-27T10:02:08.707+00:00","event":"HTTP_compressed_body","pre_compression_bytes":80337092,"post_compression_bytes":56144876,"compression_duration_ms":120} {"db_id":17158877,"utc":"2026-09-27T10:03:33.252+00:00","event":"HTTP_response_headers","status":"200"}Selected completed-response IDs for server-side correlation:
01a0e250-9a36-73a1-afda-a7c8ccd68267resp_0493514d48a94e12016ab8e9f2d94887d08de80f400de6fc8501a0e8a7-6f9c-7ce0-880a-a9d4131955f0resp_082b6067b0c672a7016aba897c6cd087d09cd02ab3602eb99701a0e8a7-6f9c-7ce0-880a-a9d4131955f0resp_082b6067b0c672a7016aba89b1999487d09e5ab224996e277cCached input is a subset of input; reasoning tokens are included in output. These completed-response records do not establish the number or usage of incomplete/retried backend requests.
chipfighter commentedon Sep 29, 2026
Same pattern here on the Windows desktop app, and it's what pushed me to build a workaround. It also fits the measurements above: once a task is on the HTTP path, every request carries the whole history again, every image included, so even a one-line follow-up uploads tens of MB.
So I built an open-source plugin for the Codex desktop app that lets you drop old images from what gets sent, without starting a new task (disclosure: I'm the author): Codex Attachment Manager.
need IMG-xxx, and you check it again.It only changes what gets sent, so it won't help with slow opening of old image-heavy threads or large local session files. Tested on Windows with Codex 26.924. On macOS it installs and starts in CI, but nobody has tried it in the desktop app yet, so a report from a Mac would help a lot.
Install it from Codex's Plugins page (add the marketplace
chipfighter/codex-attachment-manager) or with the one-line command in the README.