Skip to content

Regression: Windows Desktop 26.707.3748 remote compaction disconnects after update #32545

Open

Description

@liulidie

What version of Codex is running?

  • Codex Desktop: OpenAI.Codex_26.707.3748.0_x64
  • Bundled CLI: codex-cli 0.144.0-alpha.4

Subscription

ChatGPT Pro

Model

gpt-5.6-sol

Platform

  • Windows 10.0.19045 x64
  • Codex Desktop for Windows

Regression

This became consistently reproducible immediately after updating Codex Desktop to the version above. Before the update, automatic context compaction worked normally or at least did not fail repeatedly.

The problem occurs in multiple threads and is not specific to ChatGPT Work mode: it also reproduces in normal Codex mode.

Error

Whenever a thread reaches automatic context compaction, the compact operation frequently fails with:

Error running remote compact task: stream disconnected before completion:
Transport error: network error: error decoding response body

After this happens, the thread is often effectively unusable because every follow-up reaches compaction again and fails.

Reproduction

  1. Start or resume a Codex Desktop thread.
  2. Continue until automatic context compaction starts.
  3. Observe the remote compact request disconnect.
  4. Retry the turn.
  5. The thread reaches compaction again and commonly fails again.

This has reproduced:

  • across multiple threads;
  • in both normal Codex mode and ChatGPT Work mode;
  • after fully exiting and restarting Codex Desktop;
  • with different VPN/proxy nodes.

Normal turns continue to work before compaction begins, which suggests the network path is not generally disconnected.

Retry behavior

A visible behavioral difference after the update is that normal response-stream failures appear to retry/reconnect up to 5 times, while the remote compact operation appears to retry only about 2 times before failing permanently.

This may indicate that /responses/compact is using a different retry policy from ordinary response streaming.

Additional context

Issue #22309 was closed with a maintainer note saying that compaction had moved locally to the same endpoint as normal turns, eliminating remote compaction errors. However, this current Windows Desktop build still emits:

Error running remote compact task

That makes this look like a regression, an old remote-compaction path still being used in Desktop, or a version/feature-negotiation mismatch.

Expected behavior

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    contextIssues related to context management (including compaction)
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Jul 12, 2026
  2. github-actions commented on Jul 12, 2026

    @github-actions
    Contributor

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

    Powered by Codex Action

  3. liulidie commented on Jul 12, 2026

    @liulidie
    Author

    Additional root-cause evidence from the current source and the affected build:

    codex-rs/core/src/compact_remote_v2.rs defines:

    const MAX_REMOTE_COMPACTION_V2_STREAM_RETRIES: u64 = 2;

    The adjacent comment explicitly says the remote-compaction retry budget is intentionally smaller than the general Responses stream retry budget. This exactly matches the observed UI behavior: normal Responses failures retry/reconnect up to about 5 times, while automatic compaction stops after about 2 retries.

    The affected build reports remote_compaction_v2 stable true. As a local regression workaround, I have now set:

    [features]
    remote_compaction_v2 = false

    and verified with codex features list that the effective value is false. This routes compaction back to the previous remote implementation. I will report whether compaction becomes reliable again after reproducing the next automatic compact.

    This makes the regression window more specific: Desktop 26.707.3748.0 / CLI 0.144.0-alpha.4, with remote_compaction_v2 enabled by default.

  4. a603069124-droid commented on Jul 13, 2026

    @a603069124-droid

    I’m experiencing the same issue. Once a long-running task triggers automatic context compaction, every subsequent interaction gets stuck in the reconnect cycle, making Codex effectively unusable and causing the thread context to be lost. I’m also unable to update the task state file before the thread becomes unusable, so I have to restart Codex and manually split the task into a new thread.

  5. TheLime1 commented on Aug 2, 2026

    @TheLime1

    please fix this issue , this breaks long tasks

  6. fakerms commented on Aug 16, 2026

    @fakerms

    same issue.

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

    appIssues related to the Codex desktop appbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)contextIssues related to context management (including compaction)windows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions