Skip to content

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

Open
Open
[Windows][Remote Control] WebSocket times out with os error 10060 behind system proxy/TUN, while explicit proxy curl reaches endpoint#38768
Labels
appIssues related to the Codex desktop appbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)remotewindows-osIssues related to Codex on Windows systems

Description

@CDYbug
CDYbug
opened on Aug 15, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    remote
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    on Aug 15, 2026

  2. github-actions commented on Aug 15, 2026

    @github-actions
    github-actionsBot
    on Aug 15, 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. Lang45 commented on Aug 24, 2026

    @Lang45
    Lang45
    on Aug 24, 2026 – with ChatGPT Codex Connector

    Independent Windows result on a newer desktop build

    I can confirm the same Remote Control failure pattern on Windows, with a version-dependent result that may help narrow the launcher/transport boundary.

    • ChatGPT Desktop ordinary HTTPS traffic worked through a local HTTP proxy.
    • App-server logs repeatedly targeted the Remote Control endpoint wss://chatgpt.com/backend-api/wham/remote/control/server and failed with Windows os error 10060.
    • An intentionally incomplete WebSocket handshake sent explicitly through the local proxy received an immediate HTTP response, confirming that the proxy route could reach the endpoint.
    • The ChatGPT/Codex process tree initially had no effective HTTP_PROXY, HTTPS_PROXY, or ALL_PROXY values.
    • Supplying those variables only to the ChatGPT process tree made the QR code appear and pairing succeed.
    • The successful workaround did not enable TUN, modify Windows global routes, or require a dedicated shortcut; the normal ChatGPT entry point remained usable.
    • Changing proxy nodes did not change the failure until the WebSocket process inheritance was corrected.

    This was observed on ChatGPT Desktop package 26.818.8289.0. It complements the older result in this issue where inherited proxy variables did not fix the connection, and suggests that the effective proxy inheritance path may vary by desktop/app-server build or launch boundary.

    No raw logs, credentials, cookies, account/workspace identifiers, machine names, local paths, or real proxy ports are included.

  4. datimmor-byte commented on Sep 6, 2026

    @datimmor-byte
    datimmor-byte
    on Sep 6, 2026

    I noticed another potentially related symptom on my setup.

    Before enabling TUN, normal Codex requests were also unreliable. When I sent a prompt, Codex would often fail/reconnect several times — roughly 5 attempts in many cases — before it finally started responding.

    After enabling TUN, this behavior disappeared as well: prompts now start responding almost immediately, without those repeated reconnect attempts.

    At the same time, Remote Control changed from repeatedly failing with os error 10060 to connecting successfully.

    So in my case the comparison was roughly:

    Before TUN

    Normal Codex works, but often reconnects several times before answering
    Remote Control WebSocket repeatedly fails with 10060

    After TUN

    Normal Codex starts responding almost immediately
    Remote Control connects successfully
    Clash shows the chatgpt.com:443 connection being captured by TUN and routed through the proxy

    Since your setup already has TUN enabled, I don't think “enable TUN” itself is the general solution. My suspicion is that the important difference may be whether the relevant Codex connections are actually being captured and routed by the TUN interface.

    This is only an observation from my setup, though — I haven't confirmed whether the repeated reconnects and Remote Control failure have exactly the same root cause.

  5. AltairCardinal commented on Sep 9, 2026

    @AltairCardinal
    AltairCardinal
    on Sep 9, 2026 – with ChatGPT Codex Connector

    补充一组较新 Windows 版本上的观察，以及对应版本的源码线索（2026-09-09）。

    环境与实际表现

    • Windows x64，本机原生桌面后台。
    • 桌面 MSIX 包版本：26.901.6511.0（从安装路径读取，非 About 对话框版本）。
    • 正在运行的后台二进制报告：codex-cli 0.153.4。
    • v2rayN 系统代理指向本机 mixed HTTP/SOCKS5 入口；期望不启用 TUN。
    • 普通 Codex 任务可正常运行。TCP 快照显示同一后台 codex.exe 存在到本机代理的连接。
    • 远程访问无法正常启用，app-server 日志反复出现以下错误。本例是 10054，与主报告中的 10060 不同。

    脱敏错误摘录（仅保留诊断字段）：

    target=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: 远程主机强迫关闭了一个现有的连接。 (os error 10054)
has_enrollment=true

    有界网络对照

    向同一 endpoint 的 HTTPS 地址发送不带认证、无 WebSocket Upgrade 的 GET，保持 TLS 校验：

    路径 观察
    直连 curl exit 35，connection reset，没有 HTTP 响应
    显式本机 HTTP 代理 CONNECT 200，TLS 验证通过，HTTP 426
    显式本机 SOCKS5h 代理 TLS 验证通过，HTTP 426

    这些结果只证明代理能到达该 endpoint，不能证明带认证的 WebSocket 握手或完整远程操作成功。没有把 curl 测试当作 production 连接验收。

    工具子进程环境未见 HTTP_PROXY / HTTPS_PROXY / ALL_PROXY；未直接读取正在运行的 app-server 的完整环境，因此不声称已证明其环境变量为空。也尚未抓取失败 WebSocket 的确切 socket 路由。

    对应 0.153.4 的源码线索

    1. remote_control/websocket.rs 的 connect_remote_control_websocket 直接调用 connect_async(request)。
    2. Cargo.toml 将 tokio-tungstenite patch 到 OpenAI fork commit 0e5b2d73aa18dd9f0a50ee9ff199d5aef7594186。
    3. 该依赖的 connect_socket 在启用 proxy feature 时调用 ProxyConfig::from_env(request.uri())；没有代理时直接连接目标。在这个连接路径中未见 Windows 系统代理解析。
    4. 与之相比，公共 HTTP 客户端的 outbound_proxy.rs 提供 HttpClientFactory::resolve_proxy_route，包含系统代理解析，并明确将 ws/wss 映射至对应 HTTP scheme。

    这支持一个具体假设：Remote Control 的连接未复用公共的系统代理路由解析，因此普通请求可走系统代理，但 Remote WebSocket 仍可能直连。公开源码与本机版本号对应，但尚未证明发布二进制与该 tag 完全相同，也尚未通过本机环境变量重启 A/B 验证。

    期望

    请检查 Remote Control 是否应复用公共 outbound proxy policy，并覆盖仅配置 Windows 系统代理、未设置代理环境变量的场景。失败诊断最好区分：选择直连/代理、代理握手、TLS、WebSocket Upgrade（不记录凭据）。

    本轮未修改配置、未重启后台、未安装透明代理工具；没有宣称 workaround 已验证。未上传原始日志、对话、账户标识、设备标识、主机名、用户路径或任何凭据。

  6. huanggh567-bot commented on Sep 14, 2026

    @huanggh567-bot
    huanggh567-bot
    on Sep 14, 2026 – with ChatGPT Codex Connector

    Additional reproduction on Windows 10 Pro x64 with Codex Desktop 26.908.4834.0.

    I was able to narrow this down further than my earlier proxy-path hypothesis:

    • Remote Control enrollment exists and is enabled (server_id and environment_id are present; remote_control_enabled=1).
    • Device attestation token generation succeeds (AttestationGenerateResponse { token: <redacted> }).
    • The active codex.exe app-server process itself has an Established TCP connection to the local Clash/Mihomo proxy at 127.0.0.1:7897, so this is not simply Codex bypassing the proxy.
    • At the same time, curl.exe through the exact same proxy reaches the exact Remote Control endpoint successfully 5/5 times:
    https://chatgpt.com/backend-api/wham/remote/control/server

    The five Remote endpoint probes all completed TLS successfully and returned HTTP 426 (expected for a normal HTTPS request to a WebSocket endpoint), with TLS times around 1.0–2.6s.

    Meanwhile, Codex app-server continued to fail the Remote Control WebSocket to:

    wss://chatgpt.com/backend-api/wham/remote/control/server

    with repeated Windows socket error 10060 and an occasional 10054.

    Strongest same-time contradiction:

    curl.exe
  -> 127.0.0.1:7897
  -> exact Remote endpoint
  -> TLS PASS 5/5
  -> HTTP 426

codex.exe app-server
  -> confirmed Established to 127.0.0.1:7897
  -> exact Remote WebSocket endpoint
  -> repeated 10060 / occasional 10054

    This substantially reduces the likelihood of a general Clash/upstream reachability issue, enrollment failure, attestation failure, or mobile-client attach being the first failing boundary. The first observed failure is now the Windows Codex app-server Remote Control WebSocket/proxy transport path.

    I also have sanitized logs_2.sqlite excerpts and a compact reproduction package if maintainers want them.

  7. invoker-bot commented on Sep 30, 2026

    @invoker-bot
    invoker-bot
    on Sep 30, 2026

    Additional reproduction on Windows x64 with Codex MSIX 26.928.1915.0, bundled CLI 0.159.0, and v2rayN system proxy enabled (TUN disabled).

    Remote Control repeatedly reports os error 10060. App-server sockets to external addresses remain in SYN_SENT. An unauthenticated probe to the same Remote endpoint times out directly, while explicitly using the local HTTP proxy returns HTTP 400 in about 1.2 seconds. This establishes endpoint reachability through the proxy, not a successful authenticated WebSocket handshake. Local DNS also differed from encrypted DNS, so a single root cause is not yet isolated.

    Please investigate consistent Windows system-proxy support for Remote Control and clearer proxy-route diagnostics. Explicit proxy environment variables and TUN have not yet been tested in this reproduction.

  8. huge731 commented on Oct 2, 2026

    @huge731
    huge731
    on Oct 2, 2026 – with ChatGPT Codex Connector

    Newer build reproduction: Windows 11 / Codex Desktop 26.930.2377.0 (updated 2026-10-03)

    This still reproduces on the Microsoft Store desktop build:

    • Windows 11 Pro x64, build 26200; v2rayN 7.25.1.
    • Windows system proxy is enabled and the local v2rayN/Xray HTTP listener is running; TUN is disabled. WinHTTP remains direct.
    • The bundled executable reports codex-cli 0.150.0-alpha.8.
    • Latest local app-server log: at 2026-10-03 01:23:48 +08:00, the Remote Control WebSocket to wss://chatgpt.com/backend-api/wham/remote/control/server failed with Windows socket error 10061; the next reconnect began at 01:24:13. has_enrollment=true, so enrollment is present while transport fails.
    • An unauthenticated HTTPS GET sent explicitly through the local HTTP proxy to that endpoint, without WebSocket Upgrade headers, returned HTTP 426 Upgrade Required in about 2.2 seconds. This confirms that the proxy route reaches the endpoint; it does not verify the authenticated WebSocket handshake.

    Matching source path

    The public rust-v0.150.0-alpha.8 source for remote_control/websocket.rs calls connect_async(request). The exact patched tokio-tungstenite revision (0e5b2d73aa18dd9f0a50ee9ff199d5aef7594186) resolves proxy configuration with ProxyConfig::from_env(request.uri()); its proxy feature documents HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY. If that returns no proxy, the connector opens a TCP socket to the target. I have not byte-verified that the installed binary exactly matches the public source tag, but its bundled CLI version matches.

    This supports a concrete proxy-routing gap: this Remote Control path does not read the Windows system proxy resolver in the matching source; it relies on process proxy environment variables. A process-scoped launch with those variables is a source-supported candidate, not yet tested on this machine, and requires restarting Codex.

    Expected behavior: Remote Control's WebSocket should use the configured Windows system-proxy route, without requiring whole-machine TUN or global proxy environment variables. Please expose whether the WebSocket selected a direct or proxy route in failure diagnostics.

    No credentials, account/device/server identifiers, machine name, local filesystem path, actual local proxy port, or raw logs are included.

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

    appIssues related to the Codex desktop appbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)remotewindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions