Windows proxy handling differs across Dot Cloud tasks, cua_repl, and standalone node_repl #50751

Related existing reports

• Codex Desktop Node REPL does not inherit proxy environment, causing nodeRepl.fetch and Chrome backend setup to hang on macOS #21713 — built-in Node REPL proxy environment inheritance and browser backend fetch failures (macOS).
• [Codex app] Allow stable cua_repl env overrides instead of replacing generated config on startup #42454 — generated cua_repl configuration lacks a stable environment override; earlier node_repl proxy settings do not reach the new runtime (macOS, with later Windows feedback).
• Dot tasks fail to open in desktop when the cloud WebSocket requires a proxy #49829 — Dot Cloud task WebSocket proxy handling.

This report adds a Windows 26.930.3930.0 comparison: built-in cua_repl fails while the same Chrome extension works through the bundled browser client in an explicitly proxy-configured independent node_repl, without restarting or changing proxy settings during the comparison. It does not establish that all three reports have the same root cause.

Summary

On Windows, app-level proxy configuration makes ordinary ChatGPT/Codex/Work conversations usable, but Dot-created Cloud tasks still fail to open in the desktop app. There is also a reproducible browser-tool discrepancy: built-in cua_repl fails with nodeRepl.fetch request failed, while the same Chrome extension works through the bundled browser client loaded in a separately proxy-configured node_repl.

These may be separate defects. I am reporting the observations together to document inconsistent proxy behavior across execution paths, not asserting a shared root cause.

Environment

• Windows 11 Pro, version 10.0.26300, 64-bit.
• Microsoft Store package OpenAI.Codex 26.930.3930.0.
• Bundled app package.json and Chrome/computer-use plugin version: 26.930.31730.
• Local HTTP proxy at http://127.0.0.1:10808; no TUN.
• App .env contains:

HTTP_PROXY=http://127.0.0.1:10808
HTTPS_PROXY=http://127.0.0.1:10808
NO_PROXY=localhost,127.0.0.1,::1

• The independent MCP node_repl also has these three variables explicitly set in [mcp_servers.node_repl.env].

NO_PROXY clarification

The configured NO_PROXY entries match only the listed local/loopback destinations. They do not match codex-cloud-backend.chatgpt.com and do not explain a direct connection to that cloud host. There is no evidence that this NO_PROXY configuration is faulty or that a bypass defect caused the observed cua_repl failure.

Current-session browser reproduction (2026-10-04)

1. In built-in cua_repl, select Chrome using cua.getBrowser({id:'chrome'}). Discovery succeeds.
2. Use the returned browser ID with cua.createBrowserTab(id,'https://example.com/',{sessionName:'🔎 Proxy reproduction'}).
   Actual: nodeRepl.fetch request failed after approximately 21.37 seconds.
3. In the separately configured node_repl, import scripts/browser-client.mjs from the installed bundled Chrome plugin and call setupBrowserRuntime(). Select the same Chrome extension, name the session, create a tab, navigate to the same URL, and read its URL and DOM snapshot.
   Actual: success; creation/navigation/read completed in approximately 1.11 seconds. No @oai/sky was imported.
4. Retry a simpler read in built-in cua_repl: cua.listTabs({browser:id,emit:false}).
   Actual: same fetch error after 21380 ms, recorded at 2026-10-04T00:58:05.176Z.
5. In the independent node_repl, browser.tabs.list() succeeds and includes the test tab. Screenshot capture also succeeds.

No app/runtime restart or proxy configuration change was performed during this comparison. No patched app was installed. The failure also affects listing tabs, so it is not confined to loading the destination webpage.

Owner's earlier standalone node_repl test (not repeated in this session)

1. With explicit proxy configuration: works.
2. Remove that configuration and restart: fails.
3. Restore the proxy configuration: works again.

This earlier owner-performed comparison is separate from the current browser-route reproduction above.

Dot Cloud symptom and logs

The same Dot-created tasks have a Cloud badge and can be opened on the web, but show “Check your connection” in the desktop app. Dot chat itself and the visible cloud-computer connection work.
Contemporaneous desktop logs show:

2026-10-04T00:57:05.630Z hostKind=durable transport=websocket errorCode=unknown message="WebSocket was closed before the connection was established"
2026-10-04T00:57:05.630Z hostKind=durable transport=websocket code=1006 failureReason=open_timeout
2026-10-04T00:57:40.655Z hostKind=durable transport=websocket code=1006 failureReason=open_timeout
2026-10-04T00:58:15.668Z hostKind=durable transport=websocket code=1006 failureReason=open_timeout

Earlier in this diagnostic session, unauthenticated HTTPS reachability checks to codex-cloud-backend.chatgpt.com timed out directly but returned HTTP 403 through the local proxy. This establishes reachability only, not a successful authenticated WebSocket handshake. The current reproduction collected logs without automating a new click on the desktop task.

Expected behavior / request

• Provide consistent, documented proxy handling across desktop task WebSockets and browser-tool execution environments.
• Expose a supported proxy configuration path for the built-in cua_repl transport; I have not found an equivalent to the independent node_repl environment configuration.
• Improve diagnostics to show the failing request stage, sanitized destination host, selected proxy/bypass decision and underlying error code.
• Allow these paths to work with an explicit local proxy without requiring TUN, reinstalling, or modifying the packaged application.

What is not established

The failing cua_repl request URL and low-level cause have not been captured. The comparison warrants checking whether built-in cua_repl receives and uses the intended proxy settings, but does not establish which runtime difference caused the failure. NO_PROXY/bypass is not an evidence-supported diagnosis here. The generic fetch error does not itself establish a WebSocket failure. The shared root cause with #49829 remains unproven.