[Windows App] Dragged image attachments trigger WebSocket 10054 after 26.818.8289.0 update

What version of the Codex App are you using?

OpenAI.Codex 26.818.8289.0 on Windows. The package was installed on 2026-08-25 at approximately 13:18 local time; bundled plugin assets refreshed around 13:21.

Platform

Windows x64, Codex desktop app.

Model

gpt-5.6-sol (high reasoning).

What issue are you seeing?

After the 26.818.8289.0 update, dragging or pasting an image directly into the Codex desktop composer can cause the turn to stop before the model starts processing. The UI reports:

An existing connection was forcibly closed by the remote host. (os error 10054)

The affected turn remains active with no assistant message and no tool marker. Direct image drag-and-drop worked normally before this update.

Reproduction

1. Start a new local Codex App task on Windows.
2. Confirm that text-only turns and image generation/tool-based image handling work normally.
3. Drag a PNG into the composer and send a short request.
4. Observe that the local session records the user message and inline input_image, but no model token count, reasoning item, assistant message, or tool call follows.
5. The UI reports WebSocket / remote-host error 10054, and the turn remains stuck.

A reproduced image was:

• PNG
• 2048 × 1152
• 2,603,991 bytes on disk
• approximately 3,472,898 characters when stored as the inline image message

A second reproduction used two 3840 × 2160 PNGs; the combined inline image message was approximately 8.15 MB.

Controls

• The same new task completed a long text-only/image-generation workflow successfully before the direct attachment.
• The same local image is readable through the local image tool.
• The failure occurs before the model produces tokens or calls tools.
• After the attachment failure, a text-only retry in the same task, containing only the local image path, also produced no assistant message or tool call and was interrupted after approximately 118 seconds. This suggests the session can become unusable after the first 10054 failure.
• A previous affected task was compacted from roughly 653k tokens to about 34.8k / 828k; attachment failures still reproduced in a clean takeover task, so this is not explained only by context-window exhaustion.

Expected behavior

Dragging a normal PNG into the Windows Codex App should upload and process it reliably. If transport limits are exceeded, the app should resize/compress the image or show a clear attachment-size error rather than leaving the task stuck with WebSocket 10054.

A failed attachment turn should not poison later text-only turns in the same task.

Additional information

This appears related to, but is not identical to:

• #24550 — large inline images retained in compacted replacement history
• #20805 — image-heavy chats repeatedly reconnect and become slow
• #18723 — Windows sessions become unrecoverable after WebSocket 10054

The current case reproduces on the Windows desktop app immediately after direct attachment in a newly created takeover task. Raw session files, prompts, task IDs, local paths, and images are intentionally omitted for privacy. Redacted structural evidence can be provided if needed.

Start by reproducing the failure in the Windows desktop app with a dragged PNG, then compare the attachment turn with the successful text-only and image-generation controls. Done means direct image attachments either process reliably, or oversized images receive a clear size error without poisoning later text-only turns.