codex - 💡(How to fix) Fix Codex Desktop: proactive handoff and rescue workflow for unrecoverable remote compaction failures

Summary

A long-running Codex Desktop project thread became unusable after remote compaction started failing, even for tiny prompts such as "are you there?". The error was:

{
  "error": {
    "message": "Your input exceeds the context window of this model. Please adjust your input and try again.",
    "type": "invalid_request_error",
    "param": "input",
    "code": "context_length_exceeded"
  }
}

This was especially painful because the stuck thread contained substantial project context. Once compaction failed, the thread could not produce its own handoff summary.

Environment

• Product: Codex Desktop
• Platform: Windows
• Model in thread metadata: gpt-5.5, xhigh reasoning
• Local thread metadata showed Codex CLI/app metadata around 0.118.0-alpha.2, but the user had recently updated Codex before the failure
• Thread type: long-running project thread with many pasted screenshots/images over time

What happened

The local rollout had grown very large because older prompts and tool outputs still contained embedded image data URLs from pasted screenshots. Those images were no longer needed for the active work, but they remained in the local thread history. When Codex attempted remote compaction, the compaction request itself appeared to exceed the model context window, leaving the thread unable to answer even a minimal prompt.

Recovery approach that worked

A second helper Codex thread was able to repair the broken thread locally:

1. Identified the local rollout for the stuck thread.
2. Created a durable handoff summary as a fallback.
3. Backed up the original rollout file.
4. Replaced embedded image payloads with lightweight placeholders while preserving message/tool structure.
5. Waited until Codex was fully closed so the app would not rewrite cached state.
6. Replaced the original rollout path in place with the repaired, image-stripped rollout.
7. Restarted Codex and opened the original thread.

After this, the original thread responded successfully and appeared intact.

Observed local numbers from this case:

• Rollout reduced from about 611 MB to about 52.7 MB.
• Embedded data:image payloads reduced to zero.
• JSON parse errors after repair: zero.
• Thread became usable again after restart.

Why this matters

The most valuable Codex threads are often the ones most likely to become long, media-heavy, and hard to replace. If compaction fails after a thread has crossed the point where it can answer, the user cannot ask that same thread to summarize itself or create a handoff.

Feature requests

1. Proactively detect when a thread is approaching compaction failure risk and create a durable handoff before it becomes unusable.
2. Add a built-in rescue workflow for stuck sessions, especially one that can strip stale pasted images or oversized tool payloads while preserving text context.
3. When remote compaction fails because the compaction request itself is too large, explain that clearly and offer recovery options: create handoff, strip media payloads, fork a repaired thread, or archive large assets.
4. Provide a user-visible continuity/export mechanism for long-running project threads that does not depend on the current thread still being able to answer.
5. Consider a helper-thread pattern as an official workflow: another Codex session can inspect, summarize, and repair the local history of a stuck session under user control.

Related issues

This seems related to prior compaction/context reports such as:

• #18572
• #10823
• #19386
• #4813

The additional contribution here is the recovery pattern: a helper Codex thread was able to back up and surgically reduce the local history, after which the original thread was recoverable.