›_ Codex Issues
Codex Issues / #32545

Regression: Windows Desktop 26.707.3748 remote compaction disconnects after update

Open 💬 6 comments Opened Jul 12, 2026 by liulidie
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  • Compaction should complete reliably.
  • A failed compact operation should retry/resume or fall back without wedging the thread.
  • The compact request should use the same robust path described when #22309 was closed.
  • Retry count and request/operation IDs should be visible for diagnostics.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

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

  • #31375

Powered by Codex Action

liulidie · 1 month ago

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.

a603069124-droid · 1 month ago

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.

TheLime1 · 25 days ago

please fix this issue , this breaks long tasks

fakerms · 12 days ago

same issue.

shleder · 11 days ago

I’m collecting real compaction/recovery cases for codex-rescue, an experimental local-first diagnostic/recovery tool. Your repeated compact disconnects and effectively wedged threads are a useful case because the upstream transport error and the local persisted-session state can be evaluated separately.

If you still have an affected local thread, please try the read-only path first:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

If doctor identifies an interrupted state and you want to exercise recovery:

codex-rescue salvage --latest --fork
codex-rescue verify <rescue-id>

This does not repair the remote compact endpoint; the test is whether local evidence is diagnosed conservatively and the source rollout remains untouched. Sanitized output/versions/exit codes only, please—no raw sessions, DBs, prompts, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue