Skip to content

Long-running Codex session repeatedly fails remote compaction; fresh sessions work normally #53653

Open

Description

@2510495678dd-cpu

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

  1. Continue an existing long-running conversation with substantial context and many past tasks.
  2. The response stream fails before completion.
  3. Remote compaction for this conversation fails with the same stream error.
  4. Start a brand-new Codex conversation in the same environment: it works normally.
  5. 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

  1. Can per-conversation remote compaction or serialized conversation state cause server-side stream failures when fresh sessions work?
  2. What supported non-destructive recovery procedure preserves the original history and workspace?
  3. 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

The similarity of symptoms does not establish a shared root cause.

Activity

  1. added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    contextIssues related to context management (including compaction)
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Oct 13, 2026
  2. alphamediail commented on Oct 13, 2026

    @alphamediail

    Additional Windows Desktop reproduction (2026-10-13, Asia/Jerusalem) consistent with this report.

    • One established/long-running Codex Desktop conversation repeatedly fails at Reconnecting 5/5 with stream disconnected before completion: An error occurred while processing your request.
    • Other unrelated conversations continue working normally on the same machine/account during the incident.
    • Multiple follow-up attempts in the affected conversation fail with distinct request IDs.
    • In at least one failed turn the agent visibly completed a local file edit (+47 lines) before its response stream disconnected. Thus retrying may inadvertently repeat work already performed.
    • Screenshot confirms two terminal errors, with request IDs:
      • 09972b79-7743-4c74-96de-e30e8a744b2e
      • 24fba3df-e847-4c27-8e4d-b850c3db0327
    • The screenshot itself does not show an explicit remote-compaction error, so I cannot claim compaction is confirmed to be the failing step for this instance. Exact installed Desktop version at this occurrence has not yet been collected.

    The 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.

  3. sharpdressedcodes commented on Oct 13, 2026

    @sharpdressedcodes

    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

    • Windows 11, x64. Runtime OS version: Microsoft Windows NT 10.0.26200.0 (build 26200.0).
    • Running Windows package path identifies OpenAI.Codex_26.930.7945.0; not independently checked in the About dialog.
    • Desktop client version reported in technical logs: 26.930.61225.
    • Actual running/bundled agent executable reports codex-cli 0.160.1.
    • Model in the failed turns: gpt-6.1-sol, reasoning effort xhigh.
    • Signed in using ChatGPT. Subscription tier not independently verified.

    These package, client and agent version identifiers come from different sources and should not be treated as interchangeable.

    Reproduction and observations

    1. Continue an established conversation with substantial history.
    2. After ordinary response-stream failures, submit the one-word prompt test.
    3. Three successive inspected attempts fail during pre-turn compaction, before an assistant reply.
    4. A later controlled prompt, 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.
    Completion time on 14 October (Australia/Sydney) Prompt Duration Result
    08:46:40 test 9.635 seconds Remote compaction failed
    08:53:19 test 8.368 seconds Remote compaction failed
    08:59:06 test 17.107 seconds Remote compaction failed
    09:22:06 Reply-only diagnostic 17.570 seconds Remote compaction failed

    The latest error was:

    Error running remote compact task: stream disconnected before completion: An error occurred while processing your request. You can retry your request, or contact us through our help center at help.openai.com if the error persists. Please include the request ID 5921ffb7-d41e-482e-b4ff-d990aa9222d6 in your message.
    

    Earlier confirmed request ID: 2c51c2fe-ab6d-4ddc-b574-bf4bd652dda0.

    Technical evidence

    Read-only inspection of the saved transcript and local technical logs established:

    • The inspected transcript contains 51 completed compaction checkpoints. The last is at 07:12:01 on 14 October, before the repeated failures. All 26,992 JSONL records in the pre-diagnostic snapshot parse successfully.
    • The last recorded normal model response before the failures used 305,932 input tokens and 309,142 total tokens. The token-count event reported a 475,000-token context window. These are the last response's recorded usage, not a measurement of the failed compaction request or its effective threshold.
    • The failing path is logged as run_auto_compact{reason=ContextLimit phase=PreTurn}.
    • During the 08:59 attempt, logs record remote compaction v2 stream failed; retrying request after delay, initially with a high-demand error, then falling back to HTTP, then retries with the generic processing error. The terminal log is Failed to run pre-sampling compact.
    • A CLI recovery attempt could not initialize the same conversation because the still-running desktop app retained its writer ownership: 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.
    • The installed agent lists remote_compaction_v2 as 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    CLIIssues related to the Codex CLIbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)contextIssues related to context management (including compaction)sessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions