Windows: WebSocket transport times out with respect_system_proxy, works with HTTP_PROXY/HTTPS_PROXY #29958

Activity

1. fei1025

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jun 25, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Jun 25, 2026
3. github-actions commented on Jun 25, 2026

   

   github-actionsbot

   on Jun 25, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows remote control only works with global proxy env vars, but then all conversations fail with 403 invalid_workspace_selected #29233

   Powered by Codex Action
4. Nicolas0315 commented on Jun 25, 2026

   

   Nicolas0315

   on Jun 25, 2026

   More actions

   I put together a fork branch for this: https://github.com/openai/codex/compare/main...Nicolas0315:codex:codex/websocket-system-proxy?expand=1

   What changed:

   • Added a shared outbound route resolver for non-reqwest clients so ws:///wss:// are resolved on the same HTTP/HTTPS system proxy lanes as normal requests.
   • Threaded config.respect_system_proxy into the Responses WebSocket client.
   • When a system proxy route is explicit, Responses WebSocket now opens the proxy connection and tunnels via CONNECT before the WebSocket handshake; when the platform resolver says DIRECT, it bypasses env proxy handling; when platform resolution is unavailable, it keeps the existing tungstenite env-proxy behavior.
   • Updated ModelClient::new call sites, including core integration tests and memories startup.

   Local verification on rtx4090:

   • just fmt
   • git diff --check
   • cargo check --manifest-path codex-rs\Cargo.toml -p codex-client -p codex-api -p codex-core
   • cargo check --manifest-path codex-rs\Cargo.toml -p codex-memories-write
   • cargo test --manifest-path codex-rs\Cargo.toml -p codex-core --test responses_headers --no-run
   • cargo test --manifest-path codex-rs\Cargo.toml -p codex-core --test all --no-run
   • cargo test --manifest-path codex-rs\Cargo.toml -p codex-memories-write --no-run
   • just test -p codex-client (40 passed)
   • just test -p codex-api (131 passed)

   SSH verification:

   • rtx4090: git diff --check, cargo check for affected crates, and the two focused WebSocket/proxy tests passed over SSH.
   • cyberagent-mac-m5max: fresh clone at c38b2e9ba69cb57d197c6e5ba78b5e52ae0870f9, patch apply, git diff --check, cargo check for affected crates, and focused tests passed.
   • rtx5060ti: fresh clone, patch apply, and git diff --check passed; Rust build is blocked by host linker configuration because /usr/bin/link.exe from GNU coreutils is selected instead of MSVC link.exe.
   • nicolas2025: fresh clone at the same base, patch apply, and git diff --check passed; Rust tests are blocked because that host's cargo/rustc shims under /c/Users/ogosh/work/.cargo/bin are zero-byte files.
   • nicolas-macbook-pro: fresh clone at the same base, patch apply, and git diff --check passed; Rust tests are blocked because cargo is not installed on that host.
5. simfor99 commented on Jun 26, 2026

   

   simfor99

   on Jun 26, 2026

   More actions

   Adjacent CLI data point, not the exact same setup as the Windows app / respect_system_proxy case.

   Environment in this case:

   • Codex CLI 0.142.2
   • WSL2 Ubuntu via Windows Terminal
   • Built-in OpenAI provider / ChatGPT auth
   • No explicit HTTP_PROXY / HTTPS_PROXY env vars in the shell when inspected

   Observed:

   • WebSocket path intermittently failed with failed to send websocket request: IO error: Broken pipe (os error 32).
   • Codex then fell back to HTTP(S), and the turn completed successfully.
   • The user-visible delay was several minutes of Reconnecting... 5/5 before the working HTTP/SSE transport was used.

   So this may be a different root cause than Windows system proxy resolution. But it reinforces the same important split: HTTPS/SSE can be healthy while WebSocket transport is not, and the current retry-before-fallback behavior makes that very painful in real sessions. A first-class HTTP/SSE-only option or faster WebSocket failure fallback would help both cases.
6. gaopengbin commented on Jul 14, 2026

   

   gaopengbin

   on Jul 14, 2026

   More actions

   I built a small Windows workaround for this: https://github.com/gaopengbin/chatgpt-proxy-launcher

   It launches ChatGPT/Codex with process-scoped HTTP_PROXY/HTTPS_PROXY, without enabling a global proxy. This fixed the WebSocket proxy path in my test. Unofficial, but may help confirm the same root cause.
7. 1063716500-sketch commented on Aug 13, 2026

   

   1063716500-sketch

   on Aug 13, 2026

   More actions

   I can reproduce the same behavior specifically on the Windows Remote Control path.

   Environment

   Current installation (collected 2026-08-12):

   • Windows 10 Pro 22H2 x64, build 19045.6466
   • Codex Windows app: 26.803.10989.0
   • codex-cli / app-server: 0.147.0-alpha.6.6
   • Codex primary runtime: 26.805.11740
   • Mobile client: iOS; version not present in the Windows host logs

   Failure capture (2026-08-10):

   • Codex Windows app: 26.803.5235.0
   • codex-cli / app-server: 0.147.0-alpha.6.5
   • Existing Remote enrollment (has_enrollment=true)
   • A local HTTP proxy was available on a loopback port, and the connection required a custom CA certificate.

   With only the native Windows app running, Remote repeatedly timed out while opening its control WebSocket:

   2026-08-10 12:12:55Z INFO client=Codex Desktop has_enrollment=true
   2026-08-10 12:13:16Z WARN failed to connect to app-server remote control websocket websocket_url=wss://chatgpt.com/backend-api/wham/remote/control/server error="IO timeout (os error 10060)" reconnect_attempt=9 reconnect_delay=27.379s has_enrollment=true
   

   As a control, I stopped the competing native Remote host and launched the same bundled app-server with explicit HTTP_PROXY, HTTPS_PROXY, NO_PROXY, and the required CA certificate. It connected:

   [helper launch configuration] HTTP_PROXY/HTTPS_PROXY/NO_PROXY/CA explicitly set
   2026-08-10 11:19:01Z TRACE client=manual_pair_helper
   2026-08-10 11:19:11Z INFO connected to app-server remote control websocket websocket_url=wss://chatgpt.com/backend-api/wham/remote/control/server
   

   The explicit helper also reaches CONNECTED on the newer 0.147.0-alpha.6.6 build.

   This suggests that the native Remote app-server path did not inherit or apply the effective Windows/app proxy configuration. The host logs do not expose the resolved proxy route, so proxy inheritance is the suspected cause rather than a confirmed implementation diagnosis.

   The workaround is not practical: it requires a custom PowerShell/app-server launcher to remain open, and the normal desktop app must stay closed to avoid thread-writer contention. Expected behavior is for native Windows Remote to use the same effective proxy configuration as the app/OS, or expose a supported Remote proxy setting and an actionable diagnostic.

   The native failure was captured on 26.803.5235.0 / 0.147.0-alpha.6.5. I have not disrupted the currently active helper to re-run the same controlled native test on 26.803.10989.0.

   Official Remote documentation: https://learn.chatgpt.com/docs/remote-connections

   Account, enrollment, server/environment, installation, request, machine, proxy-node, and IP identifiers are intentionally omitted.
8. htywaa commented on Aug 29, 2026

   

   htywaa

   on Aug 29, 2026

   More actions

   I can still reproduce this in Codex App 26.825.4187.0 on Windows 11.

   My Windows system proxy is 127.0.0.1:10809. With no HTTP_PROXY / HTTPS_PROXY environment variables set, normal Codex sessions repeatedly fail the WebSocket transport (Reconnecting 1/5 ... 5/5) before falling back to HTTP, and Remote Control also fails to enable.

   I verified that the local proxy itself can reach the Remote Control endpoint successfully with an explicit curl --proxy.

   As an A/B test, I completely exited Codex, then launched the same Codex App from PowerShell with:

   HTTP_PROXY=http://127.0.0.1:10809

   HTTPS_PROXY=http://127.0.0.1:10809

   NO_PROXY=localhost,127.0.0.1,::1

   With no other change, both issues disappear:

   Responses WebSocket connects normally without the 1/5 → 5/5 retry sequence.
   Remote Control enables and works normally.

   This suggests that the Codex App WebSocket transports are not correctly honoring the Windows system proxy, while they do honor explicit HTTP_PROXY / HTTPS_PROXY environment variables.

   This may also be relevant to #38768, although in that report proxy environment variables did not fix Remote Control.
9. 256952365 commented on Aug 29, 2026

   

   256952365

   on Aug 29, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows reproduction on Codex CLI 0.150.1 (ChatGPT auth), with the same workaround.

   Environment / proxy state:

   • Windows system proxy enabled: 127.0.0.1:7897
   • HTTP_PROXY / HTTPS_PROXY / ALL_PROXY initially unset
   • WinHTTP proxy: direct
   • no $CODEX_HOME/.env
   • local proxy port 127.0.0.1:7897 is listening

   Observed without explicit proxy env vars:

   • Every codex exec attempt repeatedly showed Reconnecting... 2/5 through 5/5
   • Then: Falling back from WebSockets to HTTPS transport. request timed out
   • The turn eventually completed after fallback

   Network controls through the same Windows system proxy endpoint:

   • curl -x http://127.0.0.1:7897 https://chatgpt.com completed TLS successfully 10/10 times in one run; typical TLS time was ~0.35–0.38s (one run ~1.41s)
   • A manual WebSocket Upgrade-style request to https://chatgpt.com/backend-api/codex/responses through the same proxy reached OpenAI and returned 401 Unauthorized, confirming CONNECT + TLS + endpoint reachability

   Workaround A/B:

   1. Set only:
      HTTPS_PROXY=http://127.0.0.1:7897
   2. Re-run Codex CLI.
   3. Three consecutive pure-model runs completed with no Reconnecting messages.
   4. A subsequent real tool call also completed with no reconnect/fallback; the local command itself completed in 65ms and the full turn took 10.98s.

   Earlier, setting HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, WS_PROXY, and WSS_PROXY together also produced 5/5 runs without reconnecting, but the narrower test shows HTTPS_PROXY alone is sufficient in this environment.

   Codex Desktop on the same Windows machine also frequently shows WebSocket reconnects, so this does not appear to be limited to the CLI UI.

   This strongly suggests the WebSocket transport is not consistently honoring the Windows system proxy path, while an explicit HTTPS_PROXY makes it work reliably.

   👍React with 👍1Reacted by Blank
10. tonyfenwick8814121 commented on Sep 5, 2026

    

    tonyfenwick8814121

    on Sep 5, 2026

    More actions

    Additional Windows reproduction with a measured bandwidth impact, plus a successful narrow workaround test. This also connects the symptom in #38014 to the proxy behavior reported here.

    Environment:

    • Windows 11 x64, build 26200.
    • Current desktop package: OpenAI.Codex 26.901.5003.0.
    • Bundled/selected app-server runtime: codex-cli 0.153.3.
    • Windows system proxy enabled, pointing to a local HTTP proxy. HTTP_PROXY, HTTPS_PROXY and ALL_PROXY were absent. NO_PROXY included loopback addresses.
    • enable_request_compression, remote_compaction_v2 and compaction_image_budget report enabled.

    Observed before the workaround:

    • The current desktop app-server attempted Responses WebSocket connections six times, each timing out after approximately 15 seconds, with Reconnecting 1/5 through 5/5. Subsequent model requests used responses_http.
    • An anonymous Upgrade-style request through the same explicitly selected proxy reached the OpenAI Responses endpoint and returned HTTP 401 in 0.94 seconds. This was a connectivity control, not proof of an authenticated WebSocket connection.
    • During a retained ~34-hour proxy accounting window, codex.exe to chatgpt.com accounted for 41,595,111,921 outbound bytes (41.60 GB decimal). This window spans more than one cached runtime version. The proxy records identify processes and domains, not TLS payload contents or individual threads.
    • Retained request-compression logs independently show 79 requests totaling 5,049,234,795 compressed-body bytes in one image-heavy task family, including one body of 66,432,765 bytes. Another task family with many child agents had 1,058 requests totaling 6,542,572,869 compressed-body bytes. These are available log totals, not a complete reconciliation of all on-wire traffic, and preparation does not prove delivery of every byte.
    • A separate ongoing review task on the current runtime prepared 57 HTTP requests totaling 275,684,119 compressed-body bytes. Its retained compacted user history still contained six inline images totaling ~6.0 MB of base64/data-URL text. The image-heavy task retained 27 user images totaling ~85.9 MB. These are local reconstructed-history measurements, not decrypted HTTP captures.

    Workaround verification on the same installed 0.153.3 executable:

    1. Added HTTP_PROXY and HTTPS_PROXY pointing to the existing local proxy, plus loopback NO_PROXY, to the previously absent ~/.codex/.env. No Windows-wide proxy change was made.
    2. Started an ephemeral, read-only Codex CLI probe. A pure-text inference completed successfully.
    3. Ran a second ephemeral probe with exactly two sequential harmless local time commands and a final fixed response.
    4. The second probe logged a successful Responses WebSocket connection in 0.566 seconds, negotiated permessage-deflate, completed both tool calls, and returned the expected final response. No reconnect or HTTP fallback appeared. Process exit code was zero.

    The existing desktop process has not been restarted as part of this test, so desktop-wide recovery and sustained traffic reduction are still pending verification. Existing long histories also remain large, so an initial full send can still be expensive after a successful reconnect.

    Requested fix: apply the Windows system proxy consistently to Responses WebSockets, make HTTP fallback and its bandwidth consequences visible, and provide bounded/deduplicated handling of old inline images and full-history retries. A session-scoped fallback can otherwise turn routine tool continuations into repeated multi-megabyte uploads without an actionable warning.

    Only aggregate measurements are included here. No raw sessions, prompts, source code, images, account identifiers, thread identifiers, cookies, credentials or private endpoints are attached.
11. 5igm commented on Oct 9, 2026

    

    5igm

    on Oct 9, 2026

    More actions

    Can confirm this on Windows (Codex App 26.1007.x, MSIX) and can add the full root-cause chain, plus a config-only workaround that avoids env vars entirely.

    Symptom: enabling remote control ("Allow your device to control this computer") fails with "cannot enable remote control, please retry". Backend logs (~/.codex/logs_2.sqlite, target codex_app_server_transport::transport::remote_control::websocket) show wss://chatgpt.com/backend-api/wham/remote/control/server reconnecting forever, every attempt dying after ~21s with IO error ... (os error 10060). Enrollment/token refresh over HTTPS keeps working through the proxy the whole time.

    Root cause: the HTTP client honors the WinINET system proxy (WinHttpGetIEProxyConfigForCurrentUser is called), but the remote-control WS transport does neither — it ignores the proxy and resolves chatgpt.com with the OS resolver, then dials the resolved IP directly. On networks where that resolver returns poisoned answers (mainland China here) the dial goes to bogus IPs — we caught SYN_SENTs to 128.121.243.107 / 199.96.58.85 / 108.160.169.37, none of which are anywhere near Cloudflare — so the TCP connect just times out → WSAETIMEDOUT (10060), which is exactly the "timed out" in this issue's title. Control test: curl -x <same proxy> https://chatgpt.com/backend-api/wham/remote/control/server returns 426 Upgrade Required in under a second, so the endpoint itself is perfectly healthy through the proxy.

    Config-only workaround (nicer than env vars for the desktop app, since you can't easily inject environment variables into an MSIX activation): the binary ships two feature flags, respect_system_proxy and system_proxy_fallback. Enabling both in ~/.codex/config.toml made the WS go through the system proxy:

    [features]
    respect_system_proxy = true
    system_proxy_fallback = true

    Restart Codex afterwards. The OP already had respect_system_proxy enabled without success, and adding system_proxy_fallback = true is what fixed it here — after the restart the WS connects through the proxy (verified in the proxy's connection table) and remote control enables and stays connected. So system_proxy_fallback looks like the operative flag for the WS transport.

    From the outside this looks like the WS transport simply bypasses the outbound-proxy/system-proxy resolution path that the HTTP client uses. Also linking #39237, which looks like the same class of problem on macOS.
12. Thymos2027 commented on Oct 18, 2026

    

    Thymos2027

    on Oct 18, 2026

    More actions

    Additional Windows Desktop A/B result from Oct 18, 2026 (UTC+8):

    • Windows MSIX Codex App 26.1007.2314.0; bundled Codex CLI/app-server 0.162.0-alpha.17.2; ChatGPT auth, built-in openai model provider. Local FlClash HTTP proxy was listening at 127.0.0.1:7890.
    • Before the fix, PowerShell 7's profile set HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY, and I fully exited/relaunched the desktop app with codex app from that shell. New local Work/Codex turns still showed Reconnecting 1/5 through 5/5. The app-server logs recorded ~15-second Responses WebSocket timeouts, then falling back to HTTP; subsequent HTTPS /responses requests returned 200. The app-server had established connections to the local proxy, but that alone did not establish how its WebSocket requests were routed.
    • %USERPROFILE%\.codex\.env did not exist. I created it with only HTTP_PROXY, HTTPS_PROXY, ALL_PROXY pointing to http://127.0.0.1:7890, plus NO_PROXY=localhost,127.0.0.1,::1. This did not change the Windows-wide proxy, WinHTTP, TUN, or the model provider.
    • Control: a fresh CLI process with all proxy variables removed from its shell environment then passed codex doctor: Responses WebSocket handshake returned HTTP 101. Previously, the same no-proxy-env control timed out.
    • After fully restarting the desktop app at 22:04 local time, a newly created Work chat did not show the reconnect loop. In the post-restart log window, two Responses WebSocket connections succeeded; there were zero codex_core::responses_retry entries and no HTTP fallback entries. The new chat remained on provider openai.

    This is a verified workaround on this machine. It strongly suggests that explicitly loading proxy settings from Codex's own .env changes the desktop app-server/WebSocket path, even when launching the MSIX app from a PowerShell session whose profile already sets proxy variables. I did not inspect the live process environment or packet-level route, so the precise inheritance/routing failure is not proven. The static .env values also depend on the local proxy continuing to listen on that port.