›_ Codex Issues
Codex Issues / #29958

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

Open 💬 5 comments Opened Jun 25, 2026 by fei1025
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

0.142.1

What subscription do you have?

plus

What platform is your computer?

Windows 10

What issue are you seeing?

With network_proxy and respect_system_proxy enabled on Windows, Codex can use the system proxy for HTTPS requests, but WebSocket transport times out and falls back to HTTPS:

Falling back from WebSockets to HTTPS transport. request timed out

If I set HTTP_PROXY and HTTPS_PROXY to the same proxy, WebSocket transport works correctly. It seems WebSocket transport does not fully respect the Windows system proxy configuration.

What steps can reproduce the bug?

Behavior:

  • HTTPS requests work through Windows system proxy.
  • WebSocket transport times out and falls back to HTTPS.

When HTTP_PROXY/HTTPS_PROXY are set to the same proxy:

  • WebSocket transport works correctly.

It appears that WebSocket transport does not fully honor the Windows system proxy resolver.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29233

Powered by Codex Action

Nicolas0315 · 2 months ago

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.
simfor99 · 2 months ago

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.

gaopengbin · 1 month ago

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.

1063716500-sketch · 15 days ago

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.