Repository navigation
Regression: Windows Desktop 26.707.3748 remote compaction disconnects after update #32545
Description
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
- Start or resume a Codex Desktop thread.
- Continue until automatic context compaction starts.
- Observe the remote compact request disconnect.
- Retry the turn.
- 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 Codex gets stuck after "Error running remote compact task: stream disconnected before completion" #22309 was closed.
- Retry count and request/operation IDs should be visible for diagnostics.
Activity
github-actions commentedon Jul 12, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
liulidie commentedon Jul 12, 2026
Additional root-cause evidence from the current source and the affected build:
codex-rs/core/src/compact_remote_v2.rsdefines: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:and verified with
codex features listthat the effective value isfalse. 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/ CLI0.144.0-alpha.4, withremote_compaction_v2enabled by default.a603069124-droid commentedon Jul 13, 2026
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 commentedon Aug 2, 2026
please fix this issue , this breaks long tasks
fakerms commentedon Aug 16, 2026
same issue.