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:
- Keep the original failed session unchanged.
- Create a new session or fork from the old session.
- 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
- Insert that recovery context into the new session.
- 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:
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.
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:
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:
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:
/recapcommandcodex exec forksubcommand for headless/non-interactive fork #11750 / exec: add fork subcommand for non-interactive session forking #17568: related session forking capabilityThis 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.