›_ Codex Issues
Codex Issues / #40608

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

Open 💬 1 comment Opened Aug 25, 2026 by 46csvwv274-dev

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.

View original on GitHub ↗

1 Comment

46csvwv274-dev · 2 days ago

Follow-up evidence from a fresh task:

  • Referencing local filesystem paths does not fully avoid the failure. The agent used the local image-view tool to read four original PNGs in one batch.
  • Each source image was 2560 × 1440 and approximately 4.4–5.9 MB.
  • The tool resized each image to 2048 × 1152, but then wrote a single custom_tool_call_output line of 21,000,259 characters containing the four image payloads.
  • No task_complete event followed; the task remained active/stuck.

Control test:

  • The originals were preserved.
  • Mechanical analysis copies were created at 960 × 540 JPEG, approximately 81–111 KB each.
  • Reading one 85 KB copy through the same local image-view tool completed successfully in about 0.2 seconds.

This suggests the failure is caused by large inline multimodal tool results as well as direct composer attachments. A robust fix may need to:

  1. resize/compress images before serializing them into session/tool output,
  2. cap aggregate image payload size per model turn,
  3. avoid combining multiple multi-megabyte images into one JSONL/WebSocket message, and
  4. surface a clear payload-size error instead of leaving the task stuck.

No user images, prompts, task IDs, or local paths are included here.