Codex App reports “Context compacted” after remote compaction failed, then remains stuck reconnecting

What version of the Codex App are you using (From “About Codex” dialog)?

26.810.52044 (6662)

Bundled app-server/CLI observed in the affected run: 0.147.0-alpha.6.5

What subscription do you have?

ChatGPT subscription (exact tier is not shown in the app UI)

What platform is your computer?

Darwin 27.0.0 arm64 arm

What issue are you seeing?

A long-running Codex Desktop image-generation task became stuck during remote compaction. The thread had accumulated many rounds of image generation and image-related inputs/outputs over time. The compaction request failed, but the UI still displayed “Context compacted”, followed by “Reconnecting 2/2”. The task did not reach a truthful terminal state and had to be stopped manually.

This workload type may be relevant because repeated image-generation turns can make the persisted rollout and compacted history much larger than a text-only task.

Sanitized local log timeline (2026-08-16, Asia/Shanghai):

• thread/compact/start at 17:48:05.
• The request body was 43,810,885 bytes before compression and 32,302,356 bytes after zstd.
• The initial POST returned HTTP 200 after about 6m17s, but the response stream then failed with:
  stream disconnected before completion: Transport error: network error: error decoding response body
• The retry failed with:
  Connection failed: error sending request
• The compact task remained running until manually interrupted after about 10 minutes.
• No successful compaction record was written, despite the UI saying “Context compacted”.
• After restarting the app and resuming, the thread hit five WebSocket retries with:
  failed to send websocket request: IO error: Broken pipe (os error 32)
• The UI also showed “You stopped after 0s” for a turn that actually lasted about 63 seconds.

The affected rollout JSONL is approximately 753 MB. Local SQLite integrity checks for the Codex state/log databases all returned ok. This does not appear to be local database corruption.

What steps can reproduce the bug?

1. Use a Codex Desktop image-generation task over a long period, with repeated generated images/image inputs, many turns, and repeated context compactions.
2. Let the rollout/session file grow very large (the affected one was ~753 MB).
3. Trigger automatic or manual compaction when the active serialized request is tens of MB.
4. Observe the compaction request run for several minutes and then fail while decoding the response body.
5. Observe that Desktop can still display “Context compacted” and enter a reconnect loop instead of recording a failed terminal state.
6. Restart Desktop and resume the same task; repeated WebSocket Broken pipe retries may occur.

Affected thread ID: 019ff9a4-3eb6-7012-ab6d-81d274068f87

Compact turn ID: 01a009f8-a488-7232-bd7f-d3be7a799918

The raw rollout and logs are not attached because they contain private prompts, tool output, local paths, and creative-project content.

What is the expected behavior?

• Very large compaction inputs should be pruned/chunked, or rejected quickly with a specific size-related error.
• A failed compaction must not be shown as successfully compacted.
• The compact task should reach a terminal failure state without requiring manual interruption.
• Restart/resume should provide a clear recovery path instead of repeated transport retries.
• UI duration should reflect the actual turn duration.

Additional information

Related reports appear to cover parts of the failure, including #24550, #31375, #36059, and #36232. This report adds a measured macOS failure timeline plus the incorrect success state shown by the Desktop UI.

Network note: a TUN/VPN client was active, while macOS HTTP/HTTPS/SOCKS proxy settings were disabled. This may contribute to transport instability, but it does not explain the false “Context compacted” UI state or the missing compaction terminal record.

Start by tracing the thread/compact/start flow in the app-server/CLI and Desktop client, then follow the compaction failure into the UI status and WebSocket reconnect handling. Use the reported stream-disconnect and Broken pipe timeline as the failure case. Done means failed compaction is recorded as terminal failure, the UI does not report success, and resume provides a clear recovery path.