Responses WebSocket falls back when compacted replacement_history contains large inline images

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #24388

Powered by Codex Action

This lines up with what I see in the repo as a plausible failure boundary:

• compaction writes a CompactedItem with replacement_history: Some(new_history.clone())
• rollout reconstruction later treats replacement_history as the live replacement history
• WebSocket fallback is currently transport-level, so this specific payload-shape problem can look like a generic stream disconnect

A useful narrow test case might be: construct a compacted rollout item whose replacement_history contains one or more input_image content items with large data URLs, resume/reconstruct it, and assert either that compacted history no longer carries raw image payloads into the next sampling request or that it is converted into a bounded placeholder before the WebSocket request is built.

The key distinction in the report seems important: images outside compacted records did not trigger the fallback after sanitizing only compacted replacement_history, so I would keep the first fix/test scoped to compacted history rather than all historical multimodal content.

Adding a related Windows Desktop datapoint. Same underlying data shape as this issue (compacted.payload.replacement_history retaining inline images), but the observed symptom on my machine was Desktop session/rollout bloat and UI hangs rather than only Responses WebSocket fallback.

Environment:

• Codex Desktop Store package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Platform: Windows x64
• Date observed: 2026-06-01 local time

Sanitized structural stats from the affected rollout:

File size:                       102.44 MB
JSONL lines:                     982
Lines containing data:image:     31
Bytes in image-containing lines: 100.37 MB
data:image URI occurrences:      51
Unique image data URIs:          34
Total data:image URI bytes:      100.26 MB
compacted records:               2
bytes in compacted records:      24.74 MB
largest single record:           24.207 MB compacted record with 16 image refs
response_item user image lines:  14
event_msg user_message images:   14

Largest relevant record:

Line 757: type=compacted, ~24.207 MB, 16 data:image refs

Why I think this belongs here:

• The rollout was not large because of ordinary text; almost all bytes were inline image payloads.
• The same user-provided screenshots appear to be persisted in both response_item and event_msg forms.
• Compaction then retained prior image-heavy history inside payload.replacement_history, creating another large durable record.
• Quarantining the image-heavy rollout out of %USERPROFILE%\.codex\sessions restored Desktop responsiveness.

I also added the broader Windows Desktop hang/session-list datapoint in #24676, but this comment is specifically for the compacted replacement_history amplification aspect.

Privacy note: I am not uploading the raw rollout, screenshots, sqlite databases, or unsanitized logs because they contain private conversation/image data.

Windows confirmation: retained compacted images caused WebSocket fallback

I reproduced this on:

• codex-cli 0.144.4
• Microsoft Windows NT 10.0.26200.0 x64
• gpt-5.6-sol
• reasoning_effort=max
• OpenAI model provider

The affected long-running session repeatedly produced:

``text
Reconnecting... 4/5
Stream disconnected before completion: failed to send websocket request:
IO error: An established connection was aborted by the software in your
host machine. (os error 10053)
``

It then fell back to HTTPS and remained on HTTPS after stopping and resuming the session. Other Codex sessions on the same machine continued working normally over WebSockets, suggesting this was specific to the affected session payload rather than general network or WebSocket availability.

Structural measurements from the affected rollout before repair:

• 7,241 JSONL records
• 14 compacted records
• 90.1 MiB rollout size
• 52 input_image/data-URL occurrences
• 13 original images plus 39 copies retained in compacted replacement histories
• Latest compacted replacement_history: 82 items and 13 inline images
• Approximately 24.9 million image data-URL characters in the latest active replacement history

I closed the session, created a byte-identical backup, and performed a schema-aware cleanup:

• Replaced only typed input_image objects with small input_text placeholders
• Left encrypted_content and all other fields untouched
• Preserved the session ID, message ordering, summaries, and all 7,241 JSONL records
• Validated every JSONL record afterward

After cleanup:

• 0 input_image objects
• 0 embedded image data URLs
• Rollout size reduced from 90.1 MiB to 18.8 MiB
• The same session resumed normally
• Responses completed over WebSockets with no retries or HTTPS fallback

This provides a Windows confirmation that the retained compacted image payload was causal. It appears to be the same retention mechanism described in #33493 and #23257.

Uploaded affected thread: 019f6455-ea0e-7481-ba54-5c665a6ea33f

Uploaded investigation and recovery thread: 019f6964-aa8c-7901-9dbb-90dd8249fb05

Note: Both threads were uploaded through Codex feedback.
The affected thread contains the original WebSocket failure and HTTPS fallback. The investigation thread contains the structural rollout analysis, schema-aware image cleanup, validation results, and confirmation that the same affected session resumed successfully over WebSockets afterward.

I traced the generic disconnect message to the established Responses WebSocket close-frame path on current main (79479cd).

The pump correctly forwards Message::Close(frame), but run_websocket_response_stream currently matches Message::Close(_) and discards both the close code and reason before returning:

websocket closed by server before response.completed

That means a server close such as 1009 / Message Too Big is indistinguishable from an ordinary transport disconnect in the CLI. This explains why an oversized image-heavy replacement_history can produce five generic reconnect attempts without surfacing the actionable server reason.

I prepared a minimal diagnostic-only patch that:

• preserves and reports the close code and reason, for example code=1009 reason=Message Too Big
• keeps the existing generic message when the peer supplies no close frame
• does not change retry or HTTP fallback behavior

Patch commit: https://github.com/i69699/codex/commit/b1a2aaf

Validation on Windows:

• cargo +stable nextest run --no-fail-fast -p codex-api: 159/159 passed
• cargo +stable clippy --fix --tests --allow-dirty -p codex-api: passed with no warnings

The branch is ready if a maintainer would like to invite a PR.

macOS reproduction on the current Desktop build

I added a detailed macOS corroboration to #36232. The retained inline-image/history shape also matches the root cause tracked here.

Environment

• Codex Desktop / ChatGPT app 26.803.61601
• Bundled Codex CLI 0.147.0-alpha.6.5
• macOS 26.5, Apple Silicon (arm64)
• ChatGPT authentication with the built-in openai provider
• gpt-5.6-sol, xhigh effort

Two independent affected tasks

• Task A: 109,259,104-byte rollout; latest active post-compaction history 48,758,514 bytes; 6 retained generated images contributed 21,413,208 bytes of inline base64.
• Task B: 139,210,895-byte rollout; latest active post-compaction history 30,237,919 bytes; 7 retained generated images contributed 9,866,588 bytes of inline base64, plus several browser/screenshot records of approximately 2.4–4.7 MB each.

In both tasks, a new turn records the user message but no subsequent model event before:

stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

Other tasks in the same Desktop process, on the same network and built-in provider, remained healthy. Task A's last successful model input was only 78,018 / 258,400 tokens, so serialized history byte size appears to be a pressure signal independent of the displayed token usage.

The visible failure in these two cases reaches the HTTPS Responses endpoint rather than only surfacing a WebSocket fallback, but the causal payload signature is consistent: compaction leaves large inline image/tool payloads in the active history, and retrying the affected task resends them.

The useful boundary in your reproduction is very specific: a ~17.4 MB compacted record dominated by retained inline images, reproducible WebSocket failure from a copied session, and normal completion after removing only those compacted image payloads.

Codex Rescue cannot repair Codex’s WebSocket/HTTP path or automatically rewrite replacement_history. I’m testing whether its local oversized-record diagnosis catches this safely and remains bounded on a ~703 MB rollout. It leaves the source untouched and does not replay unknown side effects.

If you still have the pre-sanitization copy, could you run:

pipx install codex-rescue==0.1.0a3
codex-rescue sessions
codex-rescue doctor --latest

Sanitized output only is enough—no raw rollout, images, databases, prompts, paths, or secrets.

https://github.com/shleder/codex-rescue

I ran a separate local-only structural scanner against the pre-sanitization copy rather than installing another recovery tool. It does not access the network, SQLite databases, or the Codex app; it never emits source paths, session IDs, prompts, tool arguments, image contents, or source hashes. The source file's size and modification time were unchanged before and after scanning.

Public-safe result:

• Source rollout size: 496,800,226 bytes
• JSONL records: 31,119; malformed records: 0
• Compaction records: 98; records with replacement_history: 49
• Largest compacted record: 16,776,971 bytes
• Largest compacted record's replacement_history: 405 messages, 39 messages with images, 44 input_image/data-URL entries, 16,591,360 Base64 payload bytes (estimated decoded image bytes: 12,443,474)
• Latest compacted record that still contains replacement_history: 16,763,158 bytes, 410 messages, 39 messages with images, the same 44 image entries and 16,591,360 Base64 payload bytes
• Across retained replacement histories: 1,284 inline-image entries and 389,049,480 Base64 payload bytes
• No record exceeded the scanner's 64 MiB bounded JSON parsing limit

This independently confirms that the active compaction payload is dominated by retained inline image bytes. The attachments are the local read-only scanner and its public-safe JSON result.

codex-issue-24550-public-evidence.zip

Thanks — this is still useful evidence.

I won’t count it as a Codex Rescue validation because you intentionally used a separate local scanner, but the result is valuable independently: the source stayed unchanged, the rollout was valid JSONL, and the active compacted history still carried 44 inline images / ~16.6 MB of Base64 payload.

That is enough for me to keep Rescue’s scope conservative here: detect/report the oversized persisted history and require review, but not claim that it repairs the compaction/image-retention bug itself.

No need to install another tool unless you specifically want a side-by-side comparison. Thanks for keeping the output privacy-safe.

I implemented a candidate fix for the retained inline-image payload issue:

• Commit: https://github.com/i69699/codex/commit/844b23788f796339fab161c4c26da75bcffb09d4
• Compare: https://github.com/openai/codex/compare/main...i69699:fix/strip-inline-images-from-compacted-history

The change externalizes inline Base64 images returned in compacted replacement history into a content-addressed, per-thread store. Compacted history retains only bounded codex-image:// references, and view_image resolves a referenced image on demand with size, path, and SHA-256 validation. Remote image URLs remain unchanged.

Targeted compaction, storage, integrity, path-safety, follow-up request, and view_image tests pass, as does just fix -p codex-core.

I attempted to open a PR, but the compare page currently says that pull requests are limited to repository collaborators, and the API returns Resource not accessible by integration. Could a maintainer review/cherry-pick this commit, open a PR from the branch, or advise on obtaining collaborator access? I am happy to adjust the implementation based on review feedback.

Additional Windows Desktop control: the regression appears to be repeated retry/fallback scope, not image retention alone

I prepared a separate report before finding this issue. The root cause matches this issue closely, so I am adding only the new comparative evidence here instead of opening a duplicate.

Environment

• Windows 10 Home 22H2 (19045), x64
• Codex Desktop package 26.818.3698.0
• Current bundled CLI 0.149.0-alpha.4
• Affected thread created under 0.148.0-alpha.21
• gpt-5.6-sol, ChatGPT authentication
• Clash/Mihomo HTTP proxy at 127.0.0.1:7890

Affected thread

• 15 PNG inputs, about 17.2 MiB on disk
• One compacted history record retained 15 input_image entries containing 22.938 MiB of Base64 image data
• 40 recorded model requests:
• 23.07–23.87 MiB before zstd
• 17.24–17.57 MiB after zstd
• Retained logs contained at least:
• 9 × Windows socket error 10053
• 10 × Windows socket error 10054
• 5 × falling back to HTTP
• A typical failure batch uploaded/retried the same large WebSocket request five times. Each attempt took about 37 seconds, so HTTP fallback occurred only after roughly 185–188 seconds.
• Later turns or internal/delegated sessions could repeat the five-upload sequence.

Historical control

An older long thread created under 0.147.0-alpha.6.5 was substantially larger:

• final compacted history: 54 images / 55.545 MiB of Base64 image data
• 25 recorded requests, median 56.921 MiB before compression / 41.865 MiB after compression
• only one retained 10054 and one HTTP fallback
• after that fallback, 25 subsequent requests in the same session stayed on HTTP without repeating WebSocket failures

This suggests that retaining large inline images predates 0.148. The severe latency regression on this machine is the cost of retrying the complete WebSocket upload five times and not consistently preserving the HTTP fallback across later turns/internal sessions.

Confirmed workaround

Using the same ChatGPT authentication and endpoint through a custom provider with:

supports_websockets = false
wire_api = "responses"

completed both plain-text and image-input tests normally on 0.149.0-alpha.4.

This seems consistent with the fallback-scope problem addressed for delegated sessions in #38681. Could maintainers check whether durable turn_input dispatch, Guardian/delegated sessions, or Desktop reconstruction creates a new Responses client that loses the parent/thread fallback state? It would also help to expose a supported HTTP-only switch for the built-in ChatGPT provider, or to fall back after the first failed oversized WebSocket upload instead of retransmitting it five times.

Privacy note: no raw rollouts, prompts, image contents, account identifiers, or authentication data are included.

Thanks — this control makes the boundary between the two issues much clearer.

We already have separate candidate transport fixes alongside the compaction/image change:

• b11bc1b preserves the WebSocket close code/reason and maps an explicit 1009 / Message Too Big close to a non-retryable error, so that case does not retransmit the same request five times.
• 8705dc2 prevents reuse of a WebSocket whose pump task has already stopped.
• 844b237 addresses the payload source by externalizing compacted inline images into bounded content-addressed references with on-demand loading.

The important remaining gap is that the first fix only applies when the peer provides a standard 1009 close frame. Windows socket errors 10053/10054 do not necessarily expose that close frame, so they can still enter the generic retry budget. PR #38681 also preserves fallback only for delegated sessions; your data suggests that later turns, Desktop reconstruction, or another Responses client recreation path may still lose the fallback state.

I therefore think these should remain two independently reviewable fixes:

1. bound/externalize retained inline images during compaction; and
2. make oversized-request fallback durable across the task and reconstructed/derived clients, while avoiding five full retransmissions after the first deterministic oversized WebSocket failure.

Your historical control is especially useful because it shows that payload size is the trigger, while the repeated retry/fallback scope is the latency regression.

Thanks for the control experiment above - separating transport fallback loops from image retention clarifies both bugs. For anyone auditing local damage from either path, vetto rescue diagnose classifies retained oversized payloads in a rollout read-only; useful when you need to know whether a given thread is safe to resume before candidate fixes land.