Add a recovery option to start a new session from previous context after repeated compact failures

Resolved 💬 3 comments Opened May 6, 2026 by WaterWhisperer Closed Jul 1, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

CLI

What feature would you like to see?

When automatic or manual context compaction fails repeatedly, Codex would better offer a first-class recovery option:

Compaction failed repeatedly. Start a new session with recovered context from this session?

The new session should be initialized from the previous session's persisted history/context, instead of requiring the user to manually open a new session and explain what happened.

Suggested flow:

  1. Keep the original failed session unchanged.
  2. Create a new session or fork from the old session.
  3. Build a recovery context from the old session, including:
  • original user goal
  • latest user instruction
  • current workspace/cwd
  • repo/branch if available
  • files inspected or changed
  • commands/tests already run
  • completed work
  • pending tasks/blockers
  • important constraints from the conversation
  1. Insert that recovery context into the new session.
  2. Let the user continue from the latest pending task.

This should avoid relying on the same failing remote compact path if possible. If the full history cannot be replayed, Codex could create a smaller recovery package from recent turns plus local session metadata.

Additional information

This is motivated by repeated failures like:

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

In my case, automatic compaction failed, retries failed, and manual compaction also failed. The practical workaround was to start a new Codex session and explain the previous context manually.

Related issues:

  • #17392: remote compaction fails with stream disconnected before completion
  • #19558: remote compaction fails and leaves thread unusable
  • #19979: remote compact task times out and the session becomes unusable
  • #8256: resume fails for specific sessions; manual copying context to a new session works as workaround
  • #18884: asks for a manual /recap command
  • #11750 / #17568: related session forking capability

This request is not just another compact failure bug report. It is specifically about the recovery UX after compaction has already failed repeatedly.

Expected behavior:

When Codex cannot compact a long-running session, it should not strand the user. It should provide an explicit recovery path to continue in a new session with enough reconstructed context to avoid starting over.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #20439
  • #20931
  • #19979
  • #19842

Powered by Codex Action

WaterWhisperer · 3 months ago

Thanks for the duplicate suggestions. I reviewed the linked issues.

I think this issue is related to them, but not an exact duplicate.

The linked issues mostly report compact failures or sessions becoming unusable after compact fails:

  • #20439 reports being stuck after repeated compact errors, with a manual workaround of creating a new session and passing the stuck session ID.
  • #20931, #19979, and #19842 report compact/resume/context-limit failures.

So the compact failure itself can be tracked in the bug issues, but this issue is about the recovery UX when compaction cannot be completed.

etraut-openai contributor · 1 month ago

This feature request hasn't received enough upvotes, so it is being closed automatically. If you still feel this feature is needed, please open a new feature request with an updated title and description.