›_ Codex Issues
Codex Issues / #20844

Windows: ChatGPT-login Codex App and Codex CLI are unstable with SOCKS5 proxy, but recover when switched to HTTP_PROXY/HTTPS_PROXY

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

Summary

On Windows, both Codex App and Codex CLI appear to be unreliable when outbound traffic goes through a local SOCKS5 proxy.

In my setup, both products showed failures on ChatGPT backend routes such as:

  • https://chatgpt.com/backend-api/codex/responses/compact
  • https://chatgpt.com/backend-api/codex/responses
  • https://chatgpt.com/backend-api/plugins/list
  • https://chatgpt.com/backend-api//connectors/directory/list?external_logos=true

After switching the same local proxy stack from SOCKS5 env vars to explicit HTTP proxy env vars, the same setup started working.

This makes it look like SOCKS5 support is incomplete or inconsistent for some Codex network paths, especially ChatGPT backend / websocket / streaming / compact-related requests.

Versions

  • Codex CLI: 0.122.0
  • Codex App: 26.429.3425.0
  • Platform: Windows 11 x64
  • Login mode: ChatGPT account
  • Model observed in logs: gpt-5.4

Proxy setup

Failing setup

I originally had:

HTTP_PROXY=socks5://127.0.0.1:1080
HTTPS_PROXY=socks5://127.0.0.1:1080
ALL_PROXY=socks5://127.0.0.1:1080

Windows system proxy was also enabled separately.

The local proxy process was v2ray.exe.

Working setup

After changing to explicit HTTP proxy vars and removing ALL_PROXY, the behavior improved:

HTTP_PROXY=http://127.0.0.1:1081
HTTPS_PROXY=http://127.0.0.1:1081
NO_PROXY=localhost,127.0.0.1,::1,192.*,172.*

Windows system proxy was also set to:

127.0.0.1:1081

What issue are you seeing?

When using the SOCKS5-based setup, both Codex App and Codex CLI would fail with stream / compact related errors.

User-visible error:

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

I also found related log lines such as:

failed to send request for url (https://chatgpt.com/backend-api//connectors/directory/list?external_logos=true): client error (Connect): tunnel error: unexpected end of file
startup remote plugin sync failed; will retry on next app-server start error=failed to send remote plugin sync request to https://chatgpt.com/backend-api/plugins/list: error sending request for url (https://chatgpt.com/backend-api/plugins/list)

So this does not seem limited to responses/compact; other chatgpt.com/backend-api/* paths also appear affected.

Steps to reproduce

  1. On Windows, run a local SOCKS5 proxy.
  2. Set:
  • HTTP_PROXY=socks5://127.0.0.1:1080
  • HTTPS_PROXY=socks5://127.0.0.1:1080
  • ALL_PROXY=socks5://127.0.0.1:1080
  1. Start Codex CLI and/or Codex App using ChatGPT login.
  2. Use Codex normally until it needs longer-lived backend requests or context compaction.
  3. Observe stream disconnect / compact failure / backend-api request failures.
  4. Change the same machine to explicit HTTP proxy env vars:
  • HTTP_PROXY=http://127.0.0.1:1081
  • HTTPS_PROXY=http://127.0.0.1:1081
  • unset ALL_PROXY
  1. Retry the same workflows.
  2. Observe that the backend route succeeds under HTTP proxy.

Expected behavior

Codex should work reliably with SOCKS5 proxy configuration as well, or clearly document which network paths currently require explicit HTTP proxy variables.

At minimum, proxy behavior should be consistent across:

  • Codex CLI
  • Codex App
  • websocket / streaming paths
  • compact task
  • plugin / connector bootstrap paths

Additional notes

This feels related to other proxy / websocket issues already reported, especially around:

  • SOCKS-only proxy behavior
  • chatgpt.com/backend-api/*
  • websocket vs HTTP transport differences
  • app vs CLI proxy inconsistencies

Related issues:

  • #9677
  • #16360
  • #16367
  • #14080
  • #13682

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #19821
  • #20439
  • #20272
  • #19441
  • #19329

Powered by Codex Action

zixuanjiang332 · 3 months ago

Update / correction: this comment was initially added here because the failing endpoint overlaps with proxy-related reports, but the remaining issue being reported is not a proxy issue.

The initial reconnect / retry behavior has been resolved in the user's environment. The unresolved problem is specifically remote context compaction timing out or disconnecting after running for a long time:

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

I am moving the detailed report to a compaction-specific issue instead of tracking it here.

azabolo · 1 month ago

I can confirm a narrower version of this on Linux with Codex CLI 0.144.1, ChatGPT login, and an authenticated socks5h://<redacted> proxy.

A/B result

  • With the normal OpenAI provider, a Responses WebSocket request succeeds through the proxy.
  • With the same official binary and environment, I used a temporary custom provider with requires_openai_auth=true, wire_api="responses", and supports_websockets=false to isolate the HTTPS/SSE path. With retries disabled, it fails immediately with:
stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)
  • A curl GET to that exact endpoint through the same authenticated SOCKS5H URL reaches the origin and returns HTTP 405, as expected for the wrong method. This verifies proxy authentication, remote DNS, TCP, and TLS independently of Codex.
  • No persistent Codex configuration was changed for this test.

Current source path

The current workspace declares:

reqwest = { version = "0.12", features = ["cookies"] }

The HTTP client adds JSON/TLS/stream features but not Reqwest's socks feature. The default HTTP route delegates environment proxy handling to Reqwest, and the explicit route ultimately uses reqwest::Proxy::all(...).

By contrast, the Responses WebSocket client enables the forked tokio-tungstenite proxy feature. Its proxy implementation explicitly supports socks5:// and socks5h://, including proxy credentials. That matches the observed asymmetry: WebSocket works, but HTTPS fallback cannot continue through the same SOCKS proxy.

A focused fix appears to be:

  1. Enable Reqwest's socks feature in the workspace.
  2. Add an HTTP-client integration test covering authenticated socks5h, remote DNS, and NO_PROXY.
  3. Keep existing behavior unchanged for direct and HTTP-proxy users.

This would also make automatic WebSocket-to-HTTPS fallback reliable in SOCKS-only environments. If maintainers want this direction, I can prepare the focused code and test as an invited PR.