codex - 💡(How to fix) Fix Codex Desktop GPT-5.5 remote compaction fails and leaves thread unusable [5 comments, 6 participants]

Summary

Codex Desktop repeatedly fails during automatic remote context compaction after switching to GPT-5.5. Once this happens, the current thread becomes unusable and every later instruction fails, so the only practical recovery is to start a new thread.

Environment

• Product: Codex Desktop
• Model: GPT-5.5
• Auth mode: ChatGPT account
• Platform: macOS
• Date observed: 2026-04-25
• Subscription: Plus
• Codex app version: 26.423.10653

Actual behavior

When the thread context usage grows above roughly 90%, Codex automatically starts context compaction. After waiting for a long time, it fails with:

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

After this error, the current conversation can no longer execute any further instructions. The thread appears stuck in a failed compact / pre-sampling state.

Expected behavior

When automatic context compaction is required, Codex should either:

• complete the compaction successfully, or
• fail gracefully and allow the current thread to continue, retry compaction, or recover without forcing the user to abandon the thread.

Reproduction pattern

1. Use Codex Desktop with GPT-5.5.
2. Work in a long-running thread until context usage is above about 90%.
3. Let Codex trigger automatic remote context compaction.
4. Wait for the compact request to run.
5. The request fails with stream disconnected before completion for https://chatgpt.com/backend-api/codex/responses/compact.
6. Try to send another instruction in the same thread.
7. The thread remains unusable.

Notes

This looks similar to existing remote compaction failures, but it became much more frequent after the GPT-5.5 update. My guess is that GPT-5.5 long-context sessions generate larger or heavier compaction requests, making the remote compact path more likely to hit a timeout or stream disconnect. The bigger issue is that the failed compact leaves the thread unrecoverable.

Impact

This is high impact for long-running coding tasks because it tends to happen after substantial work has accumulated in the thread. When it fails, the user loses the active working context and has to manually recover from files, git diff, or handoff notes in a new thread.

Suggested fix direction

• Add retry / backoff for failed remote compact requests.
• If compaction fails, keep the thread usable and surface a recovery action instead of leaving it stuck.
• Consider exposing manual compact / handoff controls before the automatic threshold.
• Check whether there is a fixed timeout around /backend-api/codex/responses/compact, especially if failures cluster around a consistent duration.