Skip to content

Current Windows Desktop still fails remote compaction for image-heavy long-running tasks (reconnect 5/5) #36232

Open

Description

@charlesonogwu

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

  1. Keep one Codex Desktop task active across many turns.
  2. Add screenshots or browser/image-tool results over time.
  3. Allow automatic compaction to occur repeatedly.
  4. Send an otherwise routine text request when the task is near another compaction.
  5. 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

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.

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 30, 2026
  2. lanchuanshuang commented on Aug 13, 2026

    @lanchuanshuang

    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

    • Codex Desktop / ChatGPT app: 26.803.61601
    • Bundled Codex CLI: 0.147.0-alpha.6.5
    • macOS 26.5, Apple Silicon (arm64)
    • ChatGPT authentication, built-in openai provider
    • Model: gpt-5.6-sol, xhigh effort
    • Failing endpoint: https://chatgpt.com/backend-api/codex/responses

    Sanitized measurements

    Task A:

    • Append-only rollout: 109,259,104 bytes
    • Latest active history after compaction: 48,758,514 bytes
    • Active history still retained 6 generated images containing 21,413,208 bytes of inline base64
    • Last successful model input: 78,018 / 258,400 tokens

    Task B:

    • Append-only rollout: 139,210,895 bytes
    • Latest active history after compaction: 30,237,919 bytes
    • Active history still retained 7 generated images containing 9,866,588 bytes of inline base64
    • It also retained several browser/screenshot tool records between approximately 2.4 MB and 4.7 MB each
    • Last successful model input: 189,019 / 258,400 tokens

    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:

    • Other tasks using the same app version, process, model provider, and network remained healthy.
    • Both failing session metadata records use the built-in openai provider.
    • Task A failed well before exhausting the advertised token context, suggesting serialized byte size is an independent pressure signal.

    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.

  3. zdayang commented on Aug 13, 2026

    @zdayang

    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.)

  4. boombx403-byte commented on Aug 18, 2026

    @boombx403-byte

    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:

    pip install codex-rescue==0.1.0a5
    codex-rescue doctor <path-to-rollout.jsonl>

    No private files need to be uploaded; please sanitize any repository details before sharing diagnostic output.

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