[Windows][Remote Control] WebSocket times out with os error 10060 behind system proxy/TUN, while explicit proxy curl reaches endpoint

What version of the Codex App are you using?

• About dialog: 26.810.52044
• Microsoft Store package path observed: OpenAI.Codex_26.810.7004.0_x64

What subscription do you have?

ChatGPT Plus (personal workspace)

What platform is your computer?

Windows 11 x64

What issue are you seeing?

Codex/ChatGPT Desktop Remote Control cannot be enabled on Windows when the machine accesses ChatGPT through a local Clash/Mihomo proxy.

The desktop UI shows errors such as:

• Unable to enable remote control. Try again.
• Couldn't check security requirements. Try again.

The local Codex SQLite logs consistently show the Remote Control WebSocket failing with Windows socket error 10060:

codex_app_server_transport::transport::remote_control::websocket
failed to connect to app-server remote control websocket
websocket_url=wss://chatgpt.com/backend-api/wham/remote/control/server
IO error: connection attempt failed because the connected party did not properly respond after a period of time (os error 10060)

The app repeatedly retries and remains unable to establish the Remote Control connection.

Network/proxy environment

• Clash Verge / Mihomo-based client
• Clash Verge version: v1.5.8
• Mixed HTTP/SOCKS port: 127.0.0.1:7897
• System proxy: enabled
• TUN mode: enabled
• Global proxy mode: enabled
• auto-route: true
• auto-detect-interface: true
• dns-hijack: any:53
• enhanced-mode: fake-ip

I also tested:

• strict-route: false and strict-route: true
• TUN stack gvisor and mixed
• multiple proxy nodes / regions
• another physical network (mobile hotspot)

The failure remained the same.

Important diagnostic result

If I explicitly send a request through the local proxy with curl, the Remote Control endpoint is reachable immediately:

curl.exe --proxy http://127.0.0.1:7897 `
  --http1.1 `
  -i `
  -H "Connection: Upgrade" `
  -H "Upgrade: websocket" `
  -H "Sec-WebSocket-Version: 13" `
  -H "Sec-WebSocket-Key: SGVsbG9Xb3JsZDEyMzQ1Ng==" `
  https://chatgpt.com/backend-api/wham/remote/control/server

The response is immediate:

HTTP/1.1 200 Connection established
HTTP/1.1 400 Bad Request
{"detail":"Missing required websocket headers"}

This confirms that the proxy can reach the exact Remote Control endpoint and that the request reaches OpenAI/Cloudflare.

However, the Codex Remote Control WebSocket still times out with os error 10060.

Proxy environment variables also do not fix it

I launched ChatGPT Desktop from a PowerShell session after setting:

$env:HTTPS_PROXY="http://127.0.0.1:7897"
$env:HTTP_PROXY="http://127.0.0.1:7897"
$env:ALL_PROXY="http://127.0.0.1:7897"

I confirmed the variables were present in that shell and then launched ChatGPT.exe from the Microsoft Store package path so the new process would inherit them.

Remote Control still failed with the same os error 10060.

TCP diagnostics

During a failed Remote Control attempt, Get-NetTCPConnection shows connections owned by ChatGPT.exe and codex.exe stuck in SynSent on port 443.

Example (IP values vary depending on DNS/proxy state):

RemotePort    : 443
State         : SynSent
OwningProcess : <ChatGPT or codex PID>

The owning processes were verified with:

Get-Process -Id <pid> | Select-Object Id,ProcessName,Path

and corresponded to:

ChatGPT.exe
resources\codex.exe

Steps to reproduce

1. On Windows, use a local HTTP/SOCKS proxy such as Clash/Mihomo to access ChatGPT.
2. Enable system proxy and TUN mode.
3. Confirm normal ChatGPT Desktop traffic works through the proxy.
4. Open ChatGPT Desktop → Settings → Connections → Control this computer / Remote Control.
5. Click Enable / Start setup.
6. Observe Unable to enable remote control or Couldn't check security requirements.
7. Inspect %USERPROFILE%\.codex\logs_2.sqlite and filter remote_control logs.
8. Observe repeated WebSocket failures to:
   wss://chatgpt.com/backend-api/wham/remote/control/server
   with os error 10060.
9. Explicitly proxy a curl request to the same endpoint and observe an immediate HTTP response from OpenAI, showing that the proxy path itself is reachable.

What is the expected behavior?

Remote Control should use the effective Windows/proxy configuration consistently, including for its WebSocket transport, or expose a supported proxy setting for Remote Control.

At minimum, the diagnostic should report that the Remote Control WebSocket is attempting a direct connection rather than the configured proxy/TUN path.

Additional information

• MFA is enabled on the ChatGPT account.
• The account is a personal Plus account, not an Enterprise-managed workspace.
• Windows Defender firewall allows ChatGPT, Codex, Clash, and clash-meta on private/public networks.
• Changing proxy nodes did not resolve the issue.
• Changing physical network to a mobile hotspot did not resolve the issue because ChatGPT access still requires the local proxy.
• Normal ChatGPT Desktop usage works through the same proxy.

This appears related to, but not identical to, #29958 (Windows: WebSocket transport times out with respect_system_proxy, works with HTTP_PROXY/HTTPS_PROXY). In this Remote Control case, even launching the Desktop app with HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY set did not resolve the WebSocket timeout.

Privacy

I intentionally omitted authentication tokens, cookies, installation IDs, environment IDs, device IDs, and raw unfiltered logs. I can provide additional sanitized remote_control log excerpts if maintainers request them.

Start with codex_app_server_transport::transport::remote_control::websocket and the remote_control entries in %USERPROFILE%.codex\logs_2.sqlite. Compare the WebSocket connection's proxy behavior with the successful curl request to the documented endpoint. Done means Remote Control uses the effective proxy configuration or clearly reports that it is attempting a direct connection.