Bug: image-heavy chats repeatedly reconnect and become very slow
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.
7 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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.
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.
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.
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.
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.
---
This worked beautifully for me!! Thanks a ton! 😃