Full-history fork replays compacted inline images and closes Responses WebSocket before response.completed

What version of Codex is running?

• Current installed Codex CLI package: 0.148.0
• Failing fork session metadata: 0.147.0
• Parent session metadata: 0.148.0-alpha.9
• Surface: Codex Desktop / shared local Codex session storage
• Model: gpt-5.6-luna, reasoning effort max
• Platform: Windows x64

What issue are you seeing?

One long-running multimodal conversation and its full-history fork cannot complete a turn. The UI repeatedly shows:

Reconnecting... 4/5
Stream disconnected before completion: websocket closed by server before response.completed

This is thread-specific. Other very large conversations on the same machine still work, so the issue is not explained by cumulative token usage alone.

Affected sessions:

• Fork: 01a01949-a70e-7373-8bd5-6c7492f718fb
• Parent: 01a00532-f364-7fb3-9671-f144d9350aad
• The fork metadata contains forked_from_id pointing to the parent.
• Affected turn: 01a01a78-fef0-7c10-853d-b79b31ebe1a6

The Responses WebSocket handshake succeeds and the local logs show no authentication, DNS, proxy, or HTTP status failure. The server closes the stream during the turn before response.completed, and retries produce the same result.

What steps can reproduce the bug?

1. Use a long-running thread containing multiple pasted/viewed images and several context compactions.
2. Create a full-history fork of that thread.
3. Resume/send a turn in the fork.
4. Observe that the fork replays all historical compaction records almost immediately, then the response stream closes before completion.

Read-only inspection of the affected rollout files shows:

• Approximately 468 MB and about 12k JSONL records in the affected fork.
• 20 historical compacted records are replayed in approximately 1.6 seconds in the fork, although the corresponding parent compactions occurred across several days.
• The latest compacted replacement history is approximately 26.3 MB with 37 replacement items.
• Nine individual JSONL records exceed 20 MB; the largest is approximately 26.3 MB.
• Large message records contain repeated inline input_image data URLs (individual messages contain approximately 1.8–4.3 MB of image URL data).
• Image-bearing tool outputs are also persisted at approximately 1.2–3.0 MB each.

Controls from the same local Codex state:

• A working legacy thread with approximately 156M recorded tokens is approximately 106 MB, has 7 compactions, and has no JSONL record larger than 664 KB.
• A working paginated thread with approximately 21M recorded tokens has no record larger than 1.75 MB.
• The affected pair has identical large historical image records, but the fork additionally re-materializes the complete compaction chain in one burst.

No raw rollout files are attached because they contain private prompts, local paths, tool output, and image data.

What is the expected behavior?

The fork should load and complete a normal turn. Full-history forking should not duplicate/replay superseded compaction snapshots and inline image bytes into a request-sized history payload. If the payload cannot be processed, Codex should show a specific actionable error instead of retrying a WebSocket that is closed before response.completed.

Additional information

This appears related to:

• #34268 — full-history forks duplicate historical compaction snapshots and inline images.
• #24550 — large inline images in compacted replacement_history cause Responses WebSocket fallback.
• #35647 — session forks persist full parent rollout data.

The failure is reproducible from the local persisted parent/fork pair, while unrelated large conversations continue to work. A supported repair/migration path for this history was not found; manually editing the encrypted compaction records would risk corrupting the session.