Skip to content

Repeated Compact-related ERROR & Stuck in Working #20439

Closed

Description

@qlagrangian

What version of Codex CLI is running?

0.125.0

What subscription do you have?

Plus

Which model were you using?

GPT-5.5

What platform is your computer?

Darwin 25.3.0 x86_64 i386

What terminal emulator and version are you using (if applicable)?

VSCode

What issue are you seeing?

This issue happens frequently when the remaining context capacity drops to around 10%. The following error keeps appearing repeatedly:

■ Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

In short, no matter how many times I retry, the session stays stuck on Working... and nothing moves at all. Just to double-check, I ran the Nettop command and confirmed there is zero communication with the server.

It looks like there is a bug in the automatic Compact function.

Restarting the session or clearing the cache does not fix the problem. With no other options, I had to create a new Session, pass the ID of the stuck session, and instruct it to continue from there. However, getting completely stuck in a state where I have no idea what caused it was an extremely unproductive and frustrating development experience.

Please fix this urgently.

What steps can reproduce the bug?

Uploaded thread: 019dd7d4-365e-7fa0-a4bd-1b1a8dd09eb0

What is the expected behavior?

No response

Additional information

No response

Activity

  1. added
    CLIIssues related to the Codex CLI
    contextIssues related to context management (including compaction)
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Apr 30, 2026
  2. qlagrangian commented on May 5, 2026

    @qlagrangian
    Author

    chore: note NordVPN 300s timeout limit on Codex requests

    Confirmed that Codex "Remote Compact" fails consistently at exactly
    300s when NordVPN is active.
    This is independent of the Codex server's
    actual response time and is enforced by the VPN layer.

    [Problem]
    Users accessing Codex via VPN encounter excessive wait times during
    "Remote Compact" operations when the context is large, leading to
    connection timeouts.

    [Cause]

    • The VPN server (specifically NordVPN) has a strict 300-second (5-minute)
      timeout threshold.
    • If the server-side processing exceeds this limit, the VPN terminates
      the connection regardless of the actual server status.

    [Workaround]

    • Temporarily pause the VPN and trigger a "continue" instruction.
    • This allows the process to recover and complete the server response.
  3. presidenzo commented on May 7, 2026

    @presidenzo

    Also seeing this on Codex Desktop for macOS.

    Thread ID: 019e0390-d329-74c3-b8ab-13a32d339c9b
    Codex App: 26.429.61741 (2429)
    Error:

    Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
    

    This is still happening today (2026-05-07).

  4. qlagrangian commented on May 8, 2026

    @qlagrangian
    Author

    @codex Please fix this issue (Auto compact problem through VPN) ASAP.

  5. mshumski commented on May 8, 2026

    @mshumski
    Hit the same error.
    
    Looks like NordVPN / some proxy path kills the long silent `/responses/compact` HTTPS request after ~5 minutes:
    
    
    Error running remote compact task: stream disconnected before completion:
    error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

    Workaround that has been working fine for me:

    model_provider = "openai-chatgpt-stable"
    model_auto_compact_token_limit = 230000
    
    [model_providers.openai-chatgpt-stable]
    name = "OpenAI ChatGPT Stable"
    wire_api = "responses"
    requires_openai_auth = true
    supports_websockets = true
    request_max_retries = 20
    stream_max_retries = 20

    This keeps ChatGPT auth, but avoids the remote compact endpoint because the provider name is not exactly OpenAI, so Codex falls back to local/model-streaming compaction instead of POST /responses/compact.

    Would be good if Codex fell back to local compaction automatically when remote compact fails with a transport/network timeout.

  6. etraut-openai commented on Jun 29, 2026

    @etraut-openai
    Contributor

    Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use /feedback and open a new bug report.

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

    CLIIssues related to the Codex CLIbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)contextIssues related to context management (including compaction)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions