Skip to content

Error running remote compact task: stream disconnected before completion BUG #14559

Closed
Closed
Error running remote compact task: stream disconnected before completion BUG#14559
Labels
bugSomething isn't workingcontextIssues related to context management (including compaction)

Description

@AminoBatlog
AminoBatlog
opened on Mar 13, 2026

What version of Codex CLI is running?

codex-cli 0.114.0

What subscription do you have?

plus

Which model were you using?

gpt-5.4

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

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

powershell

What issue are you seeing?

I keep getting this issue ofternly, when I running the codex, it will sometimes getting this error duing the process, which may mess up my codes
Error running remote compact task: stream disconnected before completion: error sending request for url(https://chatgpt.com/backend-api/codex/responses/compact)
after this, this session is not usable anymore, no matter what I type in, it keep shows this error, so I have to start a new session

What steps can reproduce the bug?

Uploaded thread: 019ce554-a1ee-75a0-81a0-34ee2ba91e0b

What is the expected behavior?

it should be keep working, but just pop up this error

Additional information

No response

Activity

  1. AminoBatlog
    added
    bugSomething isn't working
    on Mar 13, 2026

  2. github-actions commented on Mar 13, 2026

    @github-actions
    github-actionsbot
    on Mar 13, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. etraut-openai
    added
    contextIssues related to context management (including compaction)
    on Mar 13, 2026

  4. IPRIT commented on Mar 13, 2026

    @IPRIT
    IPRIT
    on Mar 13, 2026

    I confirm the issue :(

  5. AminoBatlog commented on Mar 13, 2026

    @AminoBatlog
    AminoBatlog
    on Mar 13, 2026
    Author

    eventually find out it might be the internet issue, after use some reliable proxies this issue never happen again...
    but still dont know why the session will be messed up and can not be recovered

  6. Grallen commented on Mar 16, 2026

    @Grallen
    Grallen
    on Mar 16, 2026

    Your on windows, so I'm not sure it still uses reqwest, and I don't know if the Windows version has the 30 default timeout that is ridiculously short for that many tokens. But I submitted a fix for a similar problem in linux: #14860

  7. powerslid3 commented on Mar 17, 2026

    @powerslid3
    powerslid3
    on Mar 17, 2026

    Same

  8. weisonyoung commented on Mar 23, 2026

    @weisonyoung
    weisonyoung
    on Mar 23, 2026

    I confirm the issue :(

    Adjust the stream_idle_timeout_ms parameter in config.toml.
    ----------------------------demo---------------------------

    model = "gpt-5.4"
    model_reasoning_effort = "xhigh"
    personality = "pragmatic"
    sandbox_mode = "danger-full-access"
    model_provider = "def"

    [model_providers.def]
    name = "OpenAI Data Residency"
    stream_idle_timeout_ms = 600000

  9. Ada2pro commented on Mar 23, 2026

    @Ada2pro
    Ada2pro
    on Mar 23, 2026

    I confirm the issue :(

    Adjust the stream_idle_timeout_ms parameter in config.toml. ----------------------------demo---------------------------

    model = "gpt-5.4" model_reasoning_effort = "xhigh" personality = "pragmatic" sandbox_mode = "danger-full-access" model_provider = "def"

    [model_providers.def] name = "OpenAI Data Residency"

    stream_max_retries = 10

    stream_idle_timeout_ms = 600000

    this may really help me !!!

  10. Grallen commented on Mar 23, 2026

    @Grallen
    Grallen
    on Mar 23, 2026

    I confirm the issue :(

    Adjust the stream_idle_timeout_ms parameter in config.toml. ----------------------------demo---------------------------
    model = "gpt-5.4" model_reasoning_effort = "xhigh" personality = "pragmatic" sandbox_mode = "danger-full-access" model_provider = "def"
    [model_providers.def] name = "OpenAI Data Residency"

    stream_max_retries = 10

    stream_idle_timeout_ms = 600000

    this may really help me !!!

    Please let us know if you still experience issues or not. I would be grateful to find out if there is an alternative path to modify the timeout that affects compact.

  11. weisonyoung commented on Mar 24, 2026

    @weisonyoung
    weisonyoung
    on Mar 24, 2026

    I confirm the issue :(

    Adjust the stream_idle_timeout_ms parameter in config.toml. ----------------------------demo---------------------------
    model = "gpt-5.4" model_reasoning_effort = "xhigh" personality = "pragmatic" sandbox_mode = "danger-full-access" model_provider = "def"
    [model_providers.def] name = "OpenAI Data Residency"

    stream_max_retries = 10

    stream_idle_timeout_ms = 600000

    this may really help me !!!

    Please let us know if you still experience issues or not. I would be grateful to find out if there is an alternative path to modify the timeout that affects compact.

    It works on the Codex app.

  12. Grallen commented on Mar 25, 2026

    @Grallen
    Grallen
    on Mar 25, 2026

    I confirm the issue :(

    Adjust the stream_idle_timeout_ms parameter in config.toml. ----------------------------demo---------------------------
    model = "gpt-5.4" model_reasoning_effort = "xhigh" personality = "pragmatic" sandbox_mode = "danger-full-access" model_provider = "def"
    [model_providers.def] name = "OpenAI Data Residency"

    stream_max_retries = 10

    stream_idle_timeout_ms = 600000

    this may really help me !!!

    Please let us know if you still experience issues or not. I would be grateful to find out if there is an alternative path to modify the timeout that affects compact.

    It works on the Codex app.

    I confirmed this solution works for me too. On Linux (Ubuntu).

  13. cihadturhan commented on Mar 26, 2026

    @cihadturhan
    cihadturhan
    on Mar 26, 2026

    Does not work!

    Image
  14. etraut-openai
    marked Auto-compaction fails near context limit with "stream disconnected before completion" #16281 as a duplicate of this issue on Mar 30, 2026

  15. Tyux commented on Apr 2, 2026

    @Tyux
    Tyux
    on Apr 2, 2026

    Does not work!

  16. Grallen commented on Apr 2, 2026

    @Grallen
    Grallen
    on Apr 2, 2026

    Does not work!

    Image

    @cihadturhan You need the model_provider = "def" in the top section. that bottom part is just defining the def model provider. Your settings currently define def, but not specify for the app to actually use it.

    NOTE: for resuming sessions, sadly they are tied to provider. So you will not see past sessions for the default "openai" provider after the change. Though I just asked a new context to walk me through moving my old context to the new provider.

  17. lodlock commented on Apr 9, 2026

    @lodlock
    lodlock
    on Apr 9, 2026

    @cihadturhan You need the model_provider = "def" in the top section. that bottom part is just defining the def model provider. Your settings currently define def, but not specify for the app to actually use it.

    NOTE: for resuming sessions, sadly they are tied to provider. So you will not see past sessions for the default "openai" provider after the change. Though I just asked a new context to walk me through moving my old context to the new provider.

    Just to tack on to your note for future users: If you were to edit the db you can set all of the current threads to use the new provider. It requires having a sqlite editor. sqlite3 is small and free.

    1. temporarily remove the model_provider = "def" from the config file
    2. quit codex
    3. cd ~/.codex/ (or equivalent depending on OS)
    4. run: sqlite3 state_5.sqlite "UPDATE threads SET model_provider = 'def';"
    5. put back in the model_provider = "def" entry in the config file
    6. restart codex

    Once you change this entry it will view all current threads as being owned by the "def" provider. You will have your entire thread history now assigned to def with no need to manually copy them over.

  18. qixing-jk commented on Apr 9, 2026

    @qixing-jk
    qixing-jk
    on Apr 9, 2026

    I confirm the issue :(

    Adjust the stream_idle_timeout_ms parameter in config.toml. ----------------------------demo---------------------------

    model = "gpt-5.4" model_reasoning_effort = "xhigh" personality = "pragmatic" sandbox_mode = "danger-full-access" model_provider = "def"

    [model_providers.def] name = "OpenAI Data Residency" stream_idle_timeout_ms = 600000

    What is the special meaning of def and OpenAI Data Residency? Can I just use another name? I don't understand the working principle of this configuration

  19. FriendsHL commented on Apr 30, 2026

    @FriendsHL
    FriendsHL
    on Apr 30, 2026 – with ChatGPT Codex Connector

    I hit the same remote compaction failure again today, with concrete log metrics that may help narrow it down.

    Environment:

    • Codex macOS app: 26.422.62136 (2176)
    • Platform: macOS 15.6.1, Darwin 24.6.0, arm64
    • Model: gpt-5.5
    • Auth/provider: ChatGPT / OpenAI
    • Local latest Codex version cache: 0.125.0

    Visible error:

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

    Observed timestamps:

    • 2026-04-30 17:22:56 Asia/Shanghai
    • 2026-04-30 17:24:04 Asia/Shanghai

    Relevant sanitized log details from codex-tui.log:

    remote compaction failed
thread_id=019ddda4-855d-7000-99ac-586513c1b3b8
turn_id=019dddae-4b55-7a02-a892-57d875e578a3
last_api_response_total_tokens=240805
all_history_items_model_visible_bytes=892179
estimated_tokens_of_items_added_since_last_successful_api_response=2055
estimated_bytes_of_items_added_since_last_successful_api_response=8218
model_context_window_tokens=Some(258400)
failing_compaction_request_model_visible_bytes=913526
compact_error=stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)

    Immediately after the second failure:

    codex_core::session::turn: Failed to run pre-sampling compact

    Pattern:

    • The thread was near the model context limit: 240805 / 258400 tokens.
    • The failure occurred before sampling, during remote compaction.
    • Retrying the same old thread hit the same failure again.
    • Starting a new thread avoids the issue, which suggests this is tied to the remote compact path for long histories rather than local project code or local shell/tool execution.
    • I also found older local occurrences of the same compact error on 2026-04-25, with compaction request sizes around ~1MB.

    Expected behavior:

    • Remote compaction should complete, or fail with a recovery path that keeps the old thread usable.
    • If the compact request is too large or the stream is interrupted, Codex should ideally retry with a smaller compact payload or offer a manual resume/new-thread handoff instead of leaving the session blocked at pre-sampling compact.

  20. lodlock commented on May 2, 2026

    @lodlock
    lodlock
    on May 2, 2026

    Here is another potential workaround. You manually compact the thread yourself. Go to the folder that the thread is located in usually ~/.codex/sessions/(date thread was made). Then make a copy of the thread's jsonl file. Afterwards, you can start a new thread, hand this file directly to codex and tell it that it's a jsonl file in codex's format and inform it that it is too large to parse. Ask it to build a python script to compact the entries. Request for it to compact everything between but ignore the first 20 lines and last 100 or so. Once it is done you can replace the file and restart codex. Then the thread will compact.

    In my case the issues was codex dealing with mcp servers that returned massive amounts of data that stay cached in the conversation but are too big to transfer for compacting. I was having codex generate my game graphics using comfyui and the results were being stored as base64 encoded images which bloated the token counts into the millions.

    Here is the prompt (with reasoning) that I provided codex:
    "I have a massive Codex .jsonl session file named rollout-b11c.jsonl. It is bloated to 34 million tokens because of massive ComfyUI MCP tool payloads.

    Please write and execute a local Python script to perform a 'structural compaction' on this file. The script should read the file line-by-line, parse the JSON, and do the following:

    If the line is a normal user or assistant message, keep it exactly as is.

    If the line contains a function_call to mcp__comfyui__, modify the arguments string. Strip out any massive data but leave a summary like: {"control_type": "depth", "status": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVR42mNkYAAAAAYAAjCB0C8AAAAASUVORK5CYII="}.

    If the line is a function_call_output from comfyui, replace the massive output payload with a simple summary string: "[Tool execution successful. Image generated and saved. Detailed JSON output removed for context compaction.]"

    Save the modified lines to a new file named compacted_rollout.jsonl.

    Ensure the script maintains perfectly valid JSONL syntax for every line so it doesn't break the chat application."

    Hope this helps. It has worked for me twice now. Now I can just run the python file it made and I can skip the AI for this step entirely.

  21. FriendsHL commented on May 2, 2026

    @FriendsHL
    FriendsHL
    on May 2, 2026 via email

  22. zixuanjiang332 commented on May 3, 2026

    @zixuanjiang332
    zixuanjiang332
    on May 3, 2026 – with ChatGPT Codex Connector

    Additional reproduction details and temporary workaround that may help isolate the failure:

    The user initially suspected VPN / network configuration, but reproduced the same remote compaction failure across multiple environments:

    • Codex App on Windows, Linux, and macOS
    • dorm network, faculty network, and cellular network
    • after increasing local idle/request timeout settings to roughly 15 minutes

    The notable pattern is that the failing remote compaction path appears to cut out at about 5m01s. This suggests the remaining failure may be tied to a fixed deadline / timeout on the special remote compact path rather than a general network/VPN problem.

    Error:

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

    Temporary workaround tested by the user:

    model = "gpt-5.5"
model_provider = "openai-local-compact"
model_reasoning_effort = "high"
model_auto_compact_token_limit = 233000
personality = "pragmatic"
approval_policy = "never"
sandbox_mode = "danger-full-access"
plan_mode_reasoning_effort = "xhigh"

[model_providers.openai-local-compact]
name = "OpenAI Local Compact"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = true
stream_idle_timeout_ms = 900000

    This is not a real alternate provider. The apparent effect is that Codex no longer detects the provider as exactly OpenAI, so it avoids the special /responses/compact remote compaction path and falls back to normal/local compaction through the regular Responses/WebSocket path.

    Observed result:

    • Several sessions that previously failed remote compaction started compacting successfully with this workaround.
    • Compaction completed in under ~10 seconds in cases that previously failed.
    • Early testing across Ubuntu and macOS showed multiple successful compactions over longer-running tasks.
    • Downside: because the provider name differs, previous Codex history/resume filtering may not show the same sessions normally.

    This seems consistent with #19400: Codex currently decides remote compaction by provider identity, not by whether the active model / endpoint combination can reliably use /responses/compact.

    Possible fix directions:

    • Add an explicit user config option to disable remote compaction, e.g. remote_compaction = "never" or use_remote_compaction = false.
    • Make remote compaction model/endpoint aware, and fall back to local compaction when /responses/compact fails or times out.
    • If the remote compact endpoint has a fixed timeout around 5 minutes, expose/document it or make the client retry/fallback gracefully.

    This workaround should probably be treated only as temporary, but it strongly suggests the normal Responses path is healthy while the special remote compact endpoint is the brittle part.

  23. joelreymont commented on May 5, 2026

    @joelreymont
    joelreymont
    on May 5, 2026

    Thread ID 019dc54d-4fe7-7f12-a99c-678425fc5aee.

    No VPN.

  24. yuweuii commented on May 15, 2026

    @yuweuii
    yuweuii
    on May 15, 2026 – with ChatGPT Codex Connector

    @etraut-openai looping you in because you previously commented in #14860 that increasing timeouts may paper over an underlying latency issue.

    I opened a focused diagnostic issue here: #22798

    The goal is not to claim that all /responses/compact failures are caused by the user's network. It is to give users a concrete way to test one specific failure class: whether the same network/proxy/VPN/gateway path used by Codex can keep a long-idle HTTPS request alive for more than 90 seconds.

    The proposed self-test uses slee.pt, which intentionally waits before replying. This is different from a basic connectivity check against chatgpt.com, because the failure mode here is about surviving a long silent wait, not just DNS/TLS/connectivity.

    If slee.pt >90s is cut off early on the same path used by Codex, that user has evidence of a transport-path idle cutoff that can directly explain stream disconnected before completion during remote compaction. If it succeeds, that specific explanation becomes less likely and the report can focus more on backend/client compaction behavior.

    This may help triage the many duplicate stream disconnected before completion reports by separating network-path idle cutoff from remote compact service/client failures.

  25. Necmttn commented on Jun 22, 2026

    @Necmttn
    Necmttn
    on Jun 22, 2026

    Remote compact needs a resumable receipt, not just a longer timeout.

    Record compact task id, source thread id, request size/token estimate, started_at, last_stream_event_at, timeout source, retry count, partial summary checkpoint, and recovery action. Then a stream disconnect can resume or fall back to local/manual compaction instead of poisoning the session into repeating the same error forever.

    Generated with ax - https://github.com/Necmttn/ax

  26. FriendsHL commented on Jun 22, 2026

    @FriendsHL
    FriendsHL
    on Jun 22, 2026 via email

  27. etraut-openai commented on Jun 29, 2026

    @etraut-openai
    etraut-openai
    on Jun 29, 2026
    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.

  28. etraut-openai
    closed this as completedon Jun 29, 2026
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

    bugSomething isn't workingcontextIssues 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