Repository navigation
Current Windows Desktop still fails remote compaction for image-heavy long-running tasks (reconnect 5/5) #36232
Copy link
Copy link
Open
Labels
appIssues related to the Codex desktop appIssues related to the Codex desktop appbugSomething isn't workingSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)contextIssues related to context management (including compaction)Issues related to context management (including compaction)windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems
Description
Summary
A long-running, image-heavy Codex Desktop task repeatedly enters Reconnecting 1/5 through Reconnecting 5/5 during automatic context compaction and then reports:
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)
This is still reproducible on the current Windows Desktop build. The affected task can remain slow or unresponsive for minutes, while ordinary tasks in the same app and Codex CLI on the same machine respond normally.
Environment
- Product: Codex Desktop
- App version:
26.721.11231.0 - Platform: Windows 11 x64
- Observed: July 2026
- Task pattern: long-running task with repeated image/browser inputs and many automatic compactions
Reproduction pattern
- Keep one Codex Desktop task active across many turns.
- Add screenshots or browser/image-tool results over time.
- Allow automatic compaction to occur repeatedly.
- Send an otherwise routine text request when the task is near another compaction.
- Observe
Context automatically compacting, repeated reconnect attempts, and sometimes the remote compact error above.
Sanitized diagnostic evidence
A read-only inspection of the affected task found:
- The append-only rollout had grown past 1 GB after many compactions.
- The latest active replacement history was approximately 51 MB uncompressed (approximately 38 MB compressed).
- The active history retained dozens of historical inline images; image data accounted for nearly all payload bytes.
- The same remote-compaction stream failure recurred on multiple days.
- A compaction retry can eventually succeed, but historical image payloads remain in replacement history, so the oversized request shape and failure risk return.
- HTTP reachability and the Responses WebSocket handshake were healthy.
- Control tasks in the same Desktop process had much smaller request payloads and responded normally.
- Lowering model/reasoning effort improved an ordinary response but did not remove the oversized compaction payload or prevent recurrence.
No private rollout, screenshots, local paths, task IDs, project details, or user content are attached.
Actual behavior
- Automatic compaction sends a very large image-heavy replacement history.
- The response stream disconnects before completion.
- Desktop retries up to five times and may remain stuck or slow for minutes.
- Even after a successful retry, retained historical image bytes make the problem recur.
Expected behavior
- Compaction should summarize, externalize, or deduplicate historical image bytes rather than carry full inline payloads indefinitely.
- Request and retained-image size should remain bounded across repeated compactions.
- If remote compaction fails, Desktop should recover with a supported fallback instead of an extended reconnect loop.
- The UI should identify payload/compaction pressure distinctly from a general network failure.
Related reports
- Codex app-server reaches 27 GB footprint and 36 GB swap after compacted records grow one rollout JSONL to 10.2 GB with repeated inline PNG data URLs #34863 — repeated inline PNG data URLs make compacted records and app-server memory grow
- Responses WebSocket falls back when compacted replacement_history contains large inline images #24550 — large inline images in compacted
replacement_historytrigger Responses WebSocket fallback - stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses) #30958 — exact
stream disconnected before completionendpoint error on Windows Desktop - Context compression disconnects ~85% of the time; loses pre-compression reasoning and diverts to unrelated plans #31375 — context compression disconnects repeatedly in the Codex App
- Regression: Windows Desktop 26.707.3748 remote compaction disconnects after update #32545 — Windows Desktop remote-compaction disconnect regression
This report is intended as a current Windows Desktop corroboration tying the exact remote-compaction error and reconnect loop to measured image-heavy replacement-history payload pressure.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
appIssues related to the Codex desktop appIssues related to the Codex desktop appbugSomething isn't workingSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)contextIssues related to context management (including compaction)Issues related to context management (including compaction)windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems
Activity
github-actions commentedon Jul 30, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
lanchuanshuang commentedon Aug 13, 2026
macOS corroboration (current Desktop build)
I reproduced the same image-heavy long-task failure on macOS in two independent Codex Desktop tasks, while unrelated tasks in the same Desktop process continued to work normally.
Environment
26.803.616010.147.0-alpha.6.526.5, Apple Silicon (arm64)openaiprovidergpt-5.6-sol, xhigh efforthttps://chatgpt.com/backend-api/codex/responsesSanitized measurements
Task A:
Task B:
In both tasks, the failing turn contains the user message but no subsequent model event before:
stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)This appears consistent with retained inline image/tool payload pressure rather than a global connectivity or authentication problem:
openaiprovider.A fresh task with a text handoff works, but retrying the affected tasks resends the same oversized active history and fails again.
It would help if compaction externalized or deduplicated historical image bytes, bounded replacement-history byte size, and surfaced a payload/compaction-specific recovery path instead of a generic connectivity error.
zdayang commentedon Aug 13, 2026
Your active-history image-byte measurements suggest the old attachments, rather than the network, are still being carried forward. I built a free local Skill that scans for this and creates a clean-session handoff without modifying or uploading the rollout: Context Offload.
A scan result plus Codex version would help; no session content needed. (Disclosure: I maintain it.)
boombx403-byte commentedon Aug 18, 2026
Hi @charlesonogwu, regarding the missing tool output / unfinished call state in the transcript, Codex Rescue Alpha5 has bounded tool-correlation diagnostics to detect persisted correlation anomalies and incomplete turn boundaries without assuming non-execution.
To inspect the rollout locally and safely in read-only mode:
No private files need to be uploaded; please sanitize any repository details before sharing diagnostic output.