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

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Aug 25, 2026
2. 46csvwv274-dev commented on Aug 25, 2026

   

   46csvwv274-dev

   on Aug 25, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   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.
3. yangjiaqi55629 commented on Oct 12, 2026

   

   yangjiaqi55629

   on Oct 12, 2026 – with ChatGPT Codex Connector

   More actions

   Additional reproduction on Windows, verified on October 12, 2026.

   Environment

   • Codex desktop app: 26.1007.21434, build 13901.
   • Bundled Codex runtime: 0.162.0-alpha.17.2.
   • Model: gpt-6.1-sol.
   • Built-in OpenAI provider with ChatGPT authentication.

   User impact and reproduction

   1. Two separate desktop conversations successfully generated opaque PNG images (generation itself took approximately 39–54 seconds).
   2. Subsequent turns repeatedly stalled with:
      stream disconnected before completion: websocket closed by server before response.completed
   3. Even a subsequent text-only greeting in either affected conversation triggered the same behavior. Restarting the app did not restore reliable conversation.
   4. Other conversations continued to work normally. This has happened repeatedly after image use, rather than being a general account-wide outage.

   The affected histories each retained one inline image, with no recorded compaction. The source PNGs were valid (all PNG chunk CRCs checked), both 1672 × 941:

   • 1,569,820 bytes; approximately 2,093,118 characters as a data URL.
   • 1,615,780 bytes; approximately 2,154,398 characters as a data URL.

   Local traces showed successful WebSocket handshakes, followed by repeated disconnects after approximately 79–80 seconds. The client retried up to five times and then fell back to HTTP. Two fallback requests eventually returned HTTP 200; their uncompressed request bodies were approximately 2.46 MB and 2.62 MB. A later turn could start the WebSocket retry cycle again.

   Controlled tests
   These used separate diagnostic conversations/processes without modifying the affected chats:

   • Text-only control: completed in approximately 35 seconds.
   • Attaching an original PNG as ordinary image input, without image generation: reproduced the same WebSocket error in two attempts, stopped after approximately 100 and 110 seconds.
   • Valid small PNG control (256 × 256, 755 bytes): completed in approximately 34 seconds.
   • Converting the same source image to JPEG while preserving its 1672 × 941 dimensions (277,707 bytes): image recognition completed in approximately 60 seconds.
   • Persisting that JPEG in a conversation and then resuming with a text-only follow-up: both turns completed, approximately 40 and 53 seconds.
   • A separate end-to-end generation test preserved the original PNG locally and returned only a smaller JPEG preview (120,956 bytes). Image recognition and a subsequent text-only turn both completed in approximately 37 seconds.

   Tests with unrelated capacity/routing failures were excluded from the comparison.

   Limits of this evidence
   This is not proof of a universal 2 MB limit, a specific WebSocket close code, or a confirmed server-side root cause. The close code/reason was not captured locally. JPEG conversion changes encoding, metadata, and payload size together. The smaller-JPEG handoff is a tested workaround for these samples, not a fix for existing affected history or a guarantee for all images.

   Related reports: #44715, #38846, #28316.

   Requested fixes / maintainer guidance

   • Investigate image payload serialization and replay in subsequent conversation requests.
   • Preserve and surface the WebSocket close code/reason and actionable diagnostics.
   • Avoid repeatedly retrying an unchanged request when the same payload deterministically fails.
   • Provide a supported, non-destructive way to recover affected conversations while retaining their text history.
   • Confirm whether this is a tracked defect, and identify a fixed version or planned release when available.

   Normal image recognition and iterative work become unreliable, and affected conversations can stall for many minutes even on later text-only turns. Reducing preview size helps new tested conversations but does not resolve the underlying issue.

   Images, conversation contents, session identifiers, local paths, account details, and raw logs are intentionally omitted for privacy.