[Codex app][Windows] Chrome control fails without TUN; verified cua_repl launch.mjs proxy workaround

What version of the Codex App are you using?

Windows package version observed during diagnosis: 26.903.8094.0.
Bundled unified-computer-use / browser plugin version: 26.903.61454.
Bundled CUA Node runtime: v24.20.0.

What subscription do you have?

Not included; this report concerns local browser-control proxy handling.

What platform is your computer?

Windows 10 Pro for Workstations, x64, build 10.0.19045.
Chrome with the official Codex Chrome extension.
Local HTTP/mixed proxy: http://127.0.0.1:7890, provided by Clash Nyanpasu / mihomo.

What issue are you seeing?

Chrome control fails with TUN disabled even though the local proxy is running and Windows system proxy is configured. Turning TUN on restores browser operations. Turning it off reproduces the failure.

Before the workaround:

• Browser discovery can identify Chrome and its connected extension.
• Listing tabs, reading overall browser state, and opening a controlled tab fail with nodeRepl.fetch / request failed.
• The extension/native-host built-in diagnostics pass.
• Direct command-line HTTPS access to the browser identity endpoint fails with a connection reset, while access through the local HTTP proxy receives an HTTP response. This establishes transport reachability, not successful authentication.

The user reports that Chrome control previously worked without TUN, but we have not established the exact last working app version.

This overlaps with #42454 and #44135. The additional evidence here is a verified Windows workaround in the actual managed cua_repl process, followed by successful Chrome page operations after restarting the desktop app.

What steps can reproduce the bug?

1. Use a Windows network where the relevant OpenAI endpoints require the local HTTP proxy.
2. Keep the proxy running and Windows system proxy enabled; disable the proxy client's TUN mode.
3. Start Codex Desktop with the official Chrome plugin and a connected Chrome extension.
4. Ask Codex to inspect Chrome tabs or open and read a page.
5. Observe nodeRepl.fetch / request failed, despite successful browser discovery.
6. Enable TUN and repeat: browser operations work.
7. Disable TUN and repeat: the failure returns.

What is the expected behavior?

Browser-control backend requests should be able to use an explicitly configured HTTP proxy without requiring TUN.

Please provide a documented, stable proxy/environment override for the generated plugin runtime that survives app restarts and plugin updates. The app should retain ownership of versioned executable paths while preserving explicit user proxy settings.

Additional information: verified temporary workaround

The installed plugin manifest starts node.exe with:

%USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\26.903.61454\scripts\launch.mjs

That script then spawns the executable named by CUA_REPL_NODE_REPL_PATH (the browser-control backend). This is a plugin backend launcher, not the desktop application's main executable.

At inspection time, the plugin's .mcp.json entry for cua_repl had env_vars: [] and no explicit proxy variables. This is an observation; the exact environment filtering/inheritance layer responsible has not been conclusively identified.

After backing up launch.mjs, we inserted these seven variables immediately after ...process.env, in the child spawn(..., { env: { ... } }) block, around line 52:

 const child = spawn(executable, [], {
   env: {
     ...process.env,
+    NODE_USE_ENV_PROXY: "1",
+    HTTP_PROXY: "http://127.0.0.1:7890",
+    HTTPS_PROXY: "http://127.0.0.1:7890",
+    http_proxy: "http://127.0.0.1:7890",
+    https_proxy: "http://127.0.0.1:7890",
+    NO_PROXY: "localhost,127.0.0.1,::1",
+    no_proxy: "localhost,127.0.0.1,::1",
     NODE_REPL_TRUSTED_SERVICES: JSON.stringify({

Then we fully exited and restarted Codex, keeping the local proxy running and TUN disabled.

Actual post-restart verification on September 10, 2026:

1. The official Chrome tool successfully listed existing tabs.
2. It opened https://example.com/ and read the page's accessibility content.
3. It clicked the visible “Learn more” link.
4. It reached https://www.iana.org/help/example-domains and read the destination content.
5. It successfully closed the test tab.

This verifies actual Chrome control, beyond a standalone subprocess/environment probe. The patch also remained present after the app restart, and the bundled Node syntax check passed.

The proxy-only patch preserves the existing trusted-service configuration and does not change security/approval controls.

Limitations: This is a local workaround, not a proposed hardcoded upstream proxy. The port must match the user's running HTTP proxy. Plugin updates may overwrite the file or select a new version directory. If reapplying, back up the new version and add only the environment settings; do not replace the new launcher with an entire older file. To undo, remove the added settings or restore the matching-version backup.

An earlier edit to the legacy [mcp_servers.node_repl.env] configuration did not fix the current plugin runtime, and those additions were later absent after startup. We have not verified a durable config-only solution for this desktop build.

Related reports and workaround attribution

• #42454 — stable environment overrides for generated cua_repl
• #44135 — Windows nodeRepl.fetch failure
• #22623 — proxy/TUN-related browser helper failures
• The launcher-environment approach was adapted from the community workaround in https://github.com/openai/codex/issues/22623#issuecomment-5509468793 and verified here on Windows.

If this belongs under an existing issue, this report's Windows reproduction and verification details can be consolidated there.

Start with the generated unified-computer-use launch.mjs and the cua_repl entry in .mcp.json, then compare the related reports #42454 and #44135. Trace how proxy environment settings reach the executable named by CUA_REPL_NODE_REPL_PATH without changing trusted-service settings. Done means a durable documented override survives app restarts and plugin updates and Chrome control works with TUN disabled; the bundled Node syntax check and the reported Chrome operations provide verification points.