Skip to content

Frequent reconnect loop in Codex App: websocket closed by server before response.completed #18960

Open
Open
Frequent reconnect loop in Codex App: websocket closed by server before response.completed#18960
Labels
bugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

Description

@GGBondBlueWhale
GGBondBlueWhale
opened on Apr 22, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.417.41555 (1858)

What subscription do you have?

Pro

What platform is your computer?

macOS

What issue are you seeing?

Over the past few hours, I have repeatedly hit a streaming failure in the Codex App during normal use.

While a response is streaming, the app starts reconnecting multiple times and then fails with:

stream disconnected before completion: websocket closed by server before response.completed

The reconnect sequence I saw included:

  • Reconnecting... 2/5
  • Reconnecting... 3/5
  • Reconnecting... 4/5
  • Reconnecting... 5/5

This has happened many times within a few hours and makes the app feel noticeably slow and unreliable.

What steps can reproduce the bug?

I do not have a fully deterministic repro yet, but this is the pattern I have observed:

  1. Use the Codex App normally for some time
  2. Send a prompt that produces a streamed response
  3. During streaming, the connection drops unexpectedly
  4. The app shows repeated reconnect attempts
  5. The turn fails before response.completed

This happened multiple times over the last few hours during normal usage.

What is the expected behavior?

The stream should stay connected until the response is fully completed, or the app should recover transparently without losing the response.

Additional information

  • The failure appears intermittent, but frequent enough to significantly interrupt normal workflow
  • When it happens, I often have to retry or regenerate
  • I have a screenshot showing the reconnect loop and exact error text if needed
  • I also encountered the Reconnecting... problem multiple times within the same task, not just across separate tasks
  • Based on when I started noticing it, this appears to have been happening since around 1–2 AM US Eastern Time
  • I am reasonably confident this was not caused by my local network, because my internet connection remained stable and usable throughout the same period
  • During this same window, Codex also felt unusually slow overall, even when using GPT-5.4 in fast mode
Image Image

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Apr 22, 2026

  2. github-actions commented on Apr 22, 2026

    @github-actions
    github-actionsbot
    on Apr 22, 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. GGBondBlueWhale commented on Apr 22, 2026

    @GGBondBlueWhale
    GGBondBlueWhale
    on Apr 22, 2026 – with ChatGPT Codex Connector
    Author

    I reviewed the duplicates suggested by the bot. They look related, but not like exact duplicates of this report.

    I’m keeping this issue open because this report is specifically about the Codex App on macOS, repeated reconnects within the same task, a stable local internet connection during the failures, and unusually slow overall responses during the same time window even when using GPT-5.4 fast mode.

  4. BtcCrush commented on Apr 22, 2026

    @BtcCrush
    BtcCrush
    on Apr 22, 2026

    加一

  5. etraut-openai
    removed
    appIssues related to the Codex desktop app
    on Apr 22, 2026

  6. zkw13 commented on Apr 23, 2026

    @zkw13
    zkw13
    on Apr 23, 2026

    最近两天特别严重，UTC+8 的 14:00~18:00

  7. CaesarC commented on Apr 23, 2026

    @CaesarC
    CaesarC
    on Apr 23, 2026

    +1

  8. shanelindsay commented on Apr 23, 2026

    @shanelindsay
    shanelindsay
    on Apr 23, 2026

    suspect it is due to system updates to the expected launch of 5.5 later today, servers are flaky

  9. optimusprime123x commented on Apr 23, 2026

    @optimusprime123x
    optimusprime123x
    on Apr 23, 2026

    same problem, thread ID thread ID 019dba73-6770-7d90-aac3-6941581fc48b sent feedback twice Codex is becoming unusable for me

    Image

  10. kuzkokov commented on Apr 23, 2026

    @kuzkokov
    kuzkokov
    on Apr 23, 2026

    having the same issue for more than a week now. can't use codex at all now, so I switched to other providers.

    was trying it with both codex app and cli on macos — the result is the same.
    so, just adding to that:

    I reviewed the duplicates suggested by the bot. They look related, but not like exact duplicates of this report.

    I’m keeping this issue open because this report is specifically about the Codex App on macOS, repeated reconnects within the same task, a stable local internet connection during the failures, and unusually slow overall responses during the same time window even when using GPT-5.4 fast mode.

    it seems that it doesn't really depend on the usage method or the OS.

  11. optimusprime123x commented on Apr 23, 2026

    @optimusprime123x
    optimusprime123x
    on Apr 23, 2026

    Really hope someone looks into this wtf...

  12. lbqdly commented on Apr 24, 2026

    @lbqdly
    lbqdly
    on Apr 24, 2026

    same problem, Y ?

  13. kukudeshiyi commented on Apr 26, 2026

    @kukudeshiyi
    kukudeshiyi
    on Apr 26, 2026

    and will lose the before threads if i switch to http only mode.....hope can provide a better way as the fallback

  14. 36 remaining items

  15. paulchill commented on Jun 20, 2026

    @paulchill
    paulchill
    on Jun 20, 2026

    This is driving me nuts - in codex + vs code codex extension same issue, constantly loosing connection and thinking. burning through requests to just stop and start trying to get it to carry on.

  16. Kircerta commented on Jun 20, 2026

    @Kircerta
    Kircerta
    on Jun 20, 2026

    I also encountered "stream disconnected before completion: websocket closed by server before response.completed" issue on macOS Codex. Version 26.616.41845.

  17. hyeluoh commented on Jun 21, 2026

    @hyeluoh
    hyeluoh
    on Jun 21, 2026

    Guys, I added proxy configuration in ~/.codex/.env, and I haven't seen the reminder to reconnect five times anymore.

    cat ~/.codex/.env                                                                                                                                                                                                                
http_proxy="http://127.0.0.1:1080" 
https_proxy="http://127.0.0.1:1080"
all_proxy="socks5://127.0.0.1:1080"
no_proxy="localhost,127.0.0.1,::1,192.168.0.0/16"

  18. adhikary97 commented on Jul 12, 2026

    @adhikary97
    adhikary97
    on Jul 12, 2026

    Still get this issue everyday even for fresh chats

    Image

  19. CodeBBakGoSu commented on Jul 14, 2026

    @CodeBBakGoSu
    CodeBBakGoSu
    on Jul 14, 2026 – with ChatGPT Codex Connector

    Additional reproducible case specific to Codex App multi-agent v2:

    • Codex App: 26.707.71524 (build 5263)
    • macOS 26.5.2, arm64
    • Feature/context: multi_agent_v2 sub-agent in the Codex App
    • Sub-agent task name: slides_9_15
    • Workload: inspect six local slide images, run a local command, then continue an image-generation/editing workflow

    Observed sequence in the sub-agent card:

    1. "Viewed 6 images"
    2. "Ran command"
    3. "Agent updating"
    4. "Reconnecting ... /5"
    5. stream disconnected before completion: websocket closed by server before response.completed

    The parent task remained responsive, but the sub-agent turn never produced a completed response. Any generated result that had not already been persisted locally was effectively lost, and the sub-agent had to be interrupted/restarted.

    This seems related to the image-heavy cases already reported here, but adds a multi-agent-v2-specific failure mode: a child-agent stream can die while the parent thread remains usable. Expected behavior is either transparent child-stream recovery/resume, or a terminal child-agent error surfaced to the parent so the coordinator can retry without waiting indefinitely.

    Screenshot with the exact reconnect sequence is available.

  20. Lincoln-Muller commented on Jul 19, 2026

    @Lincoln-Muller
    Lincoln-Muller
    on Jul 19, 2026

    FOR ANYONE LOOKING FOR THE SOLUTION - READ BELOW!

    Hi all, I experienced the same issue.

    I was working on a website, and a lot of images were involved. Randomly, the thread died and I got into the compaction disconnect loop. So, I created a new Codex chat and sent the following message:

    I am currently getting:

stream disconnected before completion: websocket closed by server before response.completed

My chat seems to have broken. Here is the chat:
codex://threads/<thread ID>
<thread ID>
/Users/<not showing this here>/Documents/Codex/2026-07-18/i
Chat Name: "Create personal track website"

Whenever I send a message, it starts compacting context, and then immediately shows the "Reconnecting ... /5" and it seems to be broken. 
Can you please try and repair the chat?

    You can get the chat information by right clicking the chat and copying these 3 options:

    Image

    I used Sol medium for this task, because I wanted to make sure a dumber model like Luna or Terra wouldn't mess anything up. In a few minutes, it found the issue, fixed it, and the chat is back to normal.

    Here is what it finished with:
    Image

    Please give this message a thumbs up if it helped fix the solution for you. Sometimes, the best thing to do is to just let Codex fix its own issue.

  21. LukasWillin commented on Jul 21, 2026

    @LukasWillin
    LukasWillin
    on Jul 21, 2026

    I seemed to be able to mostly "fix" / work around this issue by following this link (https://learn.chatgpt.com/docs/config-file/config-advanced#azure-provider-and-per-provider-tuning) and setting:

    [model_providers.azure]
name = "Azure OpenAI"
base_url = "****"
env_key = "****"
wire_api = "responses"
request_max_retries = 100 # should prevent disconnect issues
stream_max_retries = 100 # should prevent disconnect issues
stream_idle_timeout_ms = 300000 # should prevent disconnect issues

    I don't know however if this works outside the Azure AI Foundry provider.

  22. maybephilipp commented on Aug 21, 2026

    @maybephilipp
    maybephilipp
    on Aug 21, 2026

    @Lincoln-Muller thank you! #18960 (comment)

    Yes — the cleanup workaround described above helped me recover a task.

    My case:

    • Long-running, image-heavy Codex Desktop task. Every new prompt triggered automatic compaction, then Reconnecting 1/5 through 5/5 and stream disconnected before completion: websocket closed by server before response.completed.
    • A fork failed too because it inherited the same history.
    • From a separate healthy task, I inspected the idle rollout: 1.35 GB, containing 254 inline data:image/...;base64,... payloads (~1.35 billion characters).
    • I backed up the rollout, replaced only custom_tool_call_output input_image items containing inline data URLs with small text markers, preserved text/metadata/remote references, validated all 4,594 JSONL records, and atomically replaced the file.
    • Archive/unarchive was required to make Codex close the old open inode and reload the cleaned rollout. File size dropped to ~6.0 MB.
    • Two no-tool health checks succeeded. A third check after reload was persisted to the cleaned inode. No reconnect loop.

    So in my case this was not a local-network failure: inline screenshots had bloated/poisoned the compaction context. Codex should store these images out-of-line, or exclude/deduplicate them when building compaction input.

  23. timbehrens12 commented on Sep 4, 2026

    @timbehrens12
    timbehrens12
    on Sep 4, 2026

    I finally fixed this after thinking Codex/networking was completely broken.

    My Codex app would repeatedly show:

    Reconnecting... waiting for network

    Eventually it would reach Reconnecting 5/5 and show:

    stream disconnected before completion: No connection could be made because the target machine actively refused it. (os error 10061)

    My internet was fine. chatgpt.com:443 was reachable, reinstalling/restarting didn't solve it, and Windows had no system proxy configured.

    The actual problem was my Codex config.

    Open this file on Windows:

    C:\Users<YOUR_USERNAME>.codex\config.toml

    Or from PowerShell:

    notepad $env:USERPROFILE.codex\config.toml

    In my config I found:

    Auto-injected by opencodex

    openai_base_url = "http://127.0.0.1:10100/v1"

    I had previously used OpenCodex, and it had modified my Codex configuration to route OpenAI requests through a local server at:

    127.0.0.1:10100

    That local server was no longer running.

    So instead of the official Codex app connecting normally to OpenAI, it was trying to connect to a dead localhost endpoint. Windows therefore returned:

    os error 10061

    which means the connection was actively refused.

    FIX

    I removed this from config.toml:

    Auto-injected by opencodex

    openai_base_url = "http://127.0.0.1:10100/v1"

    I also removed the OpenCodex custom model catalog:

    model_catalog_json = "C:\Users\\.codex\opencodex-catalog.json"

    and temporarily removed my custom OpenCodex model selection so Codex could use its normal model configuration.

    Then I saved config.toml, completely closed/restarted Codex, sent hi, and it immediately worked. No reconnect loop.

    So if you're getting error 10061:

    Before messing with your firewall, DNS, VPN, router, proxies, reinstalling Codex, etc., check ~/.codex/config.toml.

    Search for:

    openai_base_url
    127.0.0.1
    localhost

    If openai_base_url is pointing at localhost because of OpenCodex or another third-party tool, and that local service isn't running, that may be the entire problem.

    In my case, this:

    openai_base_url = "http://127.0.0.1:10100/v1"

    was 100% the cause of Codex repeatedly reconnecting and throwing Windows error 10061.

  24. ibrahimelkady2001 commented on Sep 6, 2026

    @ibrahimelkady2001
    ibrahimelkady2001
    on Sep 6, 2026

    I found at the end that the problem caused by my avast antivirus I opened avast Prefrences/Core Shields / WEB GUARD and add this urls on the exception list
    chatgpt.com
    openai.com
    auth.openai.com
    api.openai.com
    ab.chatgpt.com
    chat.openai.com
    oaistatic.com
    and also added my codex folder path in the exception list
    after that it is too much better

  25. ogpinkfloyd-stack commented on Sep 10, 2026

    @ogpinkfloyd-stack
    ogpinkfloyd-stack
    on Sep 10, 2026

    bump

  26. 1000water commented on Sep 19, 2026

    @1000water
    1000water
    on Sep 19, 2026

    Big thanks to the OpenAI team and all the contributors for the huge amount of work on Codex — the desktop app and the streaming experience are genuinely great when they work. This comment is meant to help narrow down one failure mode, not to pile on 🙂

    Same failure on Windows, with transport isolation evidence pointing to the server side

    Environment: Codex Desktop 26.915.4065.0 / codex-cli 0.155.0-alpha.9.2, Windows 10, ChatGPT account auth.

    Symptom: turns fail with stream disconnected before completion: websocket closed by server before response.completed (occasionally failed to send websocket request: IO error: ... os error 10054), UI retries 1/5→5/5 and the turn dies. Sporadic since ~Sep 11 (a few per day, retries usually recovered), then persistent for ~8 hours (Sep 19 21:00 → Sep 20 05:15 UTC+8 = Sep 19 09:00–17:15 US Eastern), then recovered on its own.

    Isolation tests run during the failure window (all through the same HTTP CONNECT proxy, same account token):

    • POST https://chatgpt.com/backend-api/codex/responses (SSE over HTTPS): succeeds every time — short requests, a 90 KB / 15 s continuous stream, and an 8 MB upload all complete normally
    • wss://chatgpt.com/backend-api/codex/responses sessions: connect + upgrade succeed, request is sent, then the server closes the socket mid-stream before response.completed, every attempt, roughly every 12–15 s
    • Full app restart with a fresh app-server process: does not fix during the window → not stale client state
    • Auth token valid, no 429s in logs, rate limit not exhausted
    • Outside the window, the same client reconnects the same websocket through the same path and works fine

    This points to server-side (or edge-side) handling of Responses websocket sessions — possibly load- or time-correlated, matching the "starts ~1–2 AM US Eastern" observation upthread — while plain HTTPS streaming on the same endpoint stays healthy.

    Workaround (verified): force HTTP transport with a custom provider that disables websockets:

    model_provider = "openai_https"

[model_providers.openai_https]
name = "OpenAI"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

    Hope the isolation data helps. Thanks again for the great work on this project!

  27. buffbuffdev commented on Sep 25, 2026

    @buffbuffdev
    buffbuffdev
    on Sep 25, 2026

    I can reproduce a very similar issue on Windows 11 with Codex CLI 0.157.0 and ChatGPT authentication.

    Minimal reproduction

    codex exec "Reply only OK"

    Actual behavior

    Codex starts normally, but the request immediately enters a reconnect loop:

    ERROR: Reconnecting... 2/5
ERROR: Reconnecting... 3/5
ERROR: Reconnecting... 4/5
ERROR: Reconnecting... 5/5

    On some attempts, Codex then reports:

    warning: Falling back from WebSockets to HTTPS transport.
stream disconnected before completion: websocket closed by server before response.completed

    I also sometimes get:

    ERROR codex_models_manager::manager: failed to refresh available models: request timed out

    The request never completes.

    Expected behavior

    The trivial request should complete normally and return:

    OK

    Troubleshooting already performed

    I have already tested all of the following:

    • Updated Codex CLI from 0.153.1 to 0.157.0
    • Logged out and logged back in with ChatGPT authentication
    • Removed an old npm-managed Codex installation
    • Reinstalled the standalone Windows Codex CLI
    • Verified that only one Codex executable remains in PATH
    • No OPENAI_* environment variables are set
    • No WinHTTP proxy is configured
    • TCP port 443 to chatgpt.com is reachable
    • IPv6 is enabled
    • Reproduced the same issue on both my normal network and on a mobile hotspot
    • codex doctor reports healthy authentication and local state
    • codex doctor successfully establishes the WebSocket handshake with HTTP 101 Switching Protocols
    • Tested with a brand-new session and a trivial prompt

    So the initial WebSocket connection succeeds, but the actual response stream disconnects before response.completed.

    This does not appear to be repository-specific, authentication-specific, or network-specific.

    Non-WebSocket isolation test

    I also tested forcing Codex to use a custom provider with WebSockets explicitly disabled:

    model_provider = "openai_https"

[model_providers.openai_https]
name = "OpenAI"
wire_api = "responses"
requires_openai_auth = true
supports_websockets = false

    Codex correctly recognized the custom provider:

    provider: openai_https

    However, even a trivial fresh request still immediately entered:

    ERROR: Reconnecting... 1/5

    So forcing the custom HTTPS/non-WebSocket provider did not resolve the issue on Codex CLI 0.157.0.

    I restored the normal OpenAI provider afterward.

    I also checked the Codex configuration for suspicious overrides such as:

    openai_base_url
localhost
127.0.0.1
custom endpoint routing

    and found none.

    Additional isolation from an independent runner

    I can now reproduce the failure outside the local interactive CLI path as well.

    An independent repository automation/runner that invokes Codex CLI also failed on a minimal probe job with the same general failure pattern:

    Codex CLI failed

    The probe was intentionally minimal:

    • no agent message was produced
    • no business/domain action was invoked
    • no repository change was made
    • the failure occurred before any meaningful task execution

    The same runner had successfully executed Codex-backed jobs earlier, so this is not a permanently broken runner configuration.

    This is important because it means the issue is no longer isolated to my local Windows CLI environment. A separate Codex CLI execution path is now failing on a minimal probe-style job as well.

    Current isolation result

    The issue therefore persists after:

    • clean standalone reinstall
    • removal of duplicate/old Codex installations
    • fresh ChatGPT authentication
    • multiple independent networks
    • confirmed TCP 443 connectivity
    • IPv6 enabled
    • no WinHTTP proxy
    • no OPENAI_* environment variables
    • healthy codex doctor results
    • successful WebSocket HTTP 101 handshake
    • explicit non-WebSocket provider test
    • fresh sessions with trivial prompts
    • independent repository-runner Codex probe failure before any business logic or repository modification

    The initial connection appears healthy, but Codex is unable to complete the actual response stream.

    At this point, the failure appears to affect more than one Codex CLI execution path and looks much more like a service/transport/session issue than a repository, local installation, authentication, proxy, or basic network connectivity problem.

  28. safdar-azeem commented on Sep 25, 2026

    @safdar-azeem
    safdar-azeem
    on Sep 25, 2026

    The problem was stale environment variables overriding Codex's ChatGPT authentication.
    Quit Codex completely, then run:

    unset OPENAI_API_KEY CODEX_API_KEY OPENAI_BASE_URL CODEX_ACCESS_TOKEN
launchctl unsetenv OPENAI_API_KEY
launchctl unsetenv CODEX_API_KEY
launchctl unsetenv OPENAI_BASE_URL
launchctl unsetenv CODEX_ACCESS_TOKEN

    Then reopen Codex. It started working immediately for me.
    If the issue returns, also check ~/.zshrc, ~/.zprofile, etc. for those variables.

  29. indiobranco commented on Sep 26, 2026

    @indiobranco
    indiobranco
    on Sep 26, 2026

    Eu tive um problema recente parecido aparecia para mim:
    unexpected status 401 Unauthorized: Incorrect API key provided: sk-svcac***********************************************************************************************************************************************************fvMA. You can find your API key at https://platform.openai.com/account/api-keys., url: https://chatgpt.com/backend-api/codex/responses, cf-ray: regewrtytrutreyutye-GRU, request id: 5y5ggf54-3f444f-5678-46vg-3e453453453

    Eu simplemente mudei para o modo ChatGPT dentro do Codex Desktop e depois voltei para o Modo Codex. E voltou a funcionar.

    O erro tinha iniciado porque o Codex tentou uma operação com depuração USB e deu falha no meio do processo

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 workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions