Repository navigation
Long-running Codex session repeatedly fails remote compaction; fresh sessions work normally #53653
Description
Summary
A specific long-running Codex conversation repeatedly fails with stream disconnected before completion. A fresh Codex conversation works normally in the same environment. The affected conversation additionally fails at remote context compaction, preventing recovery and continuation.
Observed errors
stream disconnected before completion: An error occurred while processing your request.
Error running remote compact task: stream disconnected before completion: An error occurred while processing your request.
Reproduction / comparison
- Continue an existing long-running conversation with substantial context and many past tasks.
- The response stream fails before completion.
- Remote compaction for this conversation fails with the same stream error.
- Start a brand-new Codex conversation in the same environment: it works normally.
- Retry the old conversation: it remains affected.
Environment and limitations
- Observed: 2026-10-13 (user local time UTC+08).
- Codex terminal interface; screenshot displays model label
GPT-6-Astra max. - Project workspace path indicates a Linux-style environment; exact host/client and CLI version have not been independently verified.
- The user has previously used a proxy, but no controlled network comparison has been performed.
- No evidence of a universal connectivity failure; comparison only establishes that fresh conversations work.
- Original conversation and project records must be preserved.
Expected behavior
A long-running conversation should either resume normally, complete context compaction, or offer a safe, non-destructive recovery/fork option. Repeated compaction failures should not strand an otherwise usable session.
Questions for maintainers
- Can per-conversation remote compaction or serialized conversation state cause server-side stream failures when fresh sessions work?
- What supported non-destructive recovery procedure preserves the original history and workspace?
- Can errors from remote compact return a more actionable reason and retry/fallback behavior?
Privacy
Request IDs and raw conversation content are intentionally omitted from this public issue. Two separate request IDs for the response failure and remote compaction failure are available for private support follow-up.
Related reports
- [macOS Desktop] Repeated WebSocket disconnects followed by server errors over HTTPS; remote compaction also fails at 73% context #53484 (existing conversation: remote compact failure)
- [Windows / Codex Desktop + VS Code] Intermittent stream disconnects and reconnect failures since Oct 10 #52919 (streaming and remote compact failures)
- Windows Codex Desktop: consecutive remote compaction decode failures prevent continuing a local task #50843 (compaction fails and blocks continuation)
The similarity of symptoms does not establish a shared root cause.
Activity
github-actions commentedon Oct 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
alphamediail commentedon Oct 13, 2026
Additional Windows Desktop reproduction (2026-10-13, Asia/Jerusalem) consistent with this report.
Reconnecting 5/5withstream disconnected before completion: An error occurred while processing your request.09972b79-7743-4c74-96de-e30e8a744b2e24fba3df-e847-4c27-8e4d-b850c3db0327The same Windows user also reported renderer/history-loading crashes separately in #46690. Whether that issue and this stream/compaction issue share a root cause is unknown.
Could maintainers correlate the two request IDs with backend failure logs, clarify if a specific history item or compaction state can strand an otherwise valid session, and identify a non-destructive recovery path that preserves original thread history and avoids replaying already-completed file edits?
I can provide further sanitized diagnostic evidence if useful.
sharpdressedcodes commentedon Oct 13, 2026
Current Windows reproduction of repeated compaction failure
Additional diagnostic evidence for #53653, observed 14 October 2026, Australia/Sydney (UTC+11).
The affected established conversation repeatedly fails before it can answer even a minimal prompt. The history remains readable. A separate conversation on the same installation is responding; this is an observation, not a controlled network or model comparison.
Verified environment
Microsoft Windows NT 10.0.26200.0(build26200.0).OpenAI.Codex_26.930.7945.0; not independently checked in the About dialog.26.930.61225.codex-cli 0.160.1.gpt-6.1-sol, reasoning effortxhigh.These package, client and agent version identifiers come from different sources and should not be treated as interchangeable.
Reproduction and observations
test.Reply only RECOVERY_OK. Do not use tools, change files, or continue implementation, fails the same way. No tool calls or project edits ran in that diagnostic turn.testtesttestThe latest error was:
Earlier confirmed request ID:
2c51c2fe-ab6d-4ddc-b574-bf4bd652dda0.Technical evidence
Read-only inspection of the saved transcript and local technical logs established:
run_auto_compact{reason=ContextLimit phase=PreTurn}.remote compaction v2 stream failed; retrying request after delay, initially with a high-demand error, thenfalling back to HTTP, then retries with the generic processing error. The terminal log isFailed to run pre-sampling compact.thread-store conflict ... already has an active writer. That attempt did not reach model inference or compaction and is not evidence that CLI compaction also fails.remote_compaction_v2as removed. Old advice to toggle that feature does not establish a supported workaround for this installation.Earlier closures and request
The following older reports were closed on 29 June with the explanation that compaction had moved to the normal-turn endpoint and that the change eliminated remote-compaction errors:
The current October reproduction demonstrates that a failure with this error wording can still strand an established conversation on a newer agent. It does not prove the old and new failures share a root cause or that the current implementation still uses the old dedicated compact endpoint.
Please correlate the request IDs with backend records, clarify the underlying failure and whether the June fix covers it, and provide a supported recovery procedure that preserves existing history. Please identify the affected component and a verified fixed version rather than treating the earlier closures as confirmation that this occurrence is resolved.
No raw transcript, authentication material, account identifiers, local project content or original conversation ID is included in this public report. Original records have been preserved locally.