Regression: Windows Desktop 26.707.3748 remote compaction disconnects after update
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 #22309 was closed.
- Retry count and request/operation IDs should be visible for diagnostics.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗