Skip to content

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

Open
Open
[Codex app][Windows] Chrome control fails without TUN; verified cua_repl launch.mjs proxy workaround#44364
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)windows-osIssues related to Codex on Windows systems

Description

@JackHuang90
JackHuang90
opened on Sep 10, 2026

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

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

Activity

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

  2. github-actions commented on Sep 10, 2026

    @github-actions
    github-actionsbot
    on Sep 10, 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. KNaiFen commented on Sep 10, 2026

    @KNaiFen
    KNaiFen
    on Sep 10, 2026

    The same.

  4. FanJw66 commented on Sep 11, 2026

    @FanJw66
    FanJw66
    on Sep 11, 2026

    I found a working workaround for the same Windows problem.
    The Chrome extension and native host were installed correctly. Codex could detect Chrome, but every real browser action failed with nodeRepl.fetch request failed.
    The cause was that Codex’s browser-control process was not using my Clash Verge proxy (127.0.0.1:7897).
    I fixed it by adding the proxy environment variables (NODE_USE_ENV_PROXY=1, HTTP_PROXY, HTTPS_PROXY, and NO_PROXY) to the active unified-computer-use .mcp.json file, then fully restarting Codex.
    After that, Codex successfully listed tabs, read pages, clicked links, and entered text in Chrome.
    This is a temporary workaround, not an official fix. Make sure to edit the configuration for the currently installed Codex version, because updates may replace the file. Do not treat an HTTP 403 connectivity response as proof that authentication succeeded.

  5. JackHuang90 commented on Sep 12, 2026

    @JackHuang90
    JackHuang90
    on Sep 12, 2026 – with ChatGPT Codex Connector
    Author

    Update (September 12, 2026): launcher moved into the bundled runtime; adapted workaround verified

    After another desktop update, the previous workaround stopped applying because the active launcher path changed, not just the plugin version directory.

    In the installation inspected today:

    • The unified-computer-use plugin directory is 26.908.40834.
    • Its .mcp.json now starts the bundled node.exe with this entry point:
    %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-id>\bin\node_modules\@oai\cua-repl\bin\cua-repl.mjs
    • The old unified-computer-use/<version>/scripts/launch.mjs file is no longer present in this installation.
    • The active manifest still has env_vars: [] and no explicitly configured proxy variables.
    • Bundled Node is v24.20.0; @oai/cua-repl reports 0.1.0, and @oai/browser-desktop reports 0.1.1.

    Follow the entry point in the active manifest instead of assuming the old launcher path still applies. The plugin directory version alone was insufficient to identify the launcher layout here.

    Reproduced before the new patch

    Chrome discovery succeeded, but listing tabs failed with nodeRepl.fetch request failed. The local mihomo proxy was listening on port 7890 and Windows system proxy was enabled.

    Using the same bundled Node runtime, a direct HTTPS probe failed with ECONNRESET; the explicit-proxy probe received HTTP 403. The latter only establishes transport reachability, not successful authentication. The browser service also performs an identity request before completing browser initialization. These observations point to the backend proxy path, although the exact environment inheritance/filtering layer has not been conclusively identified.

    Adapted temporary workaround

    Back up the actual bin/cua-repl.mjs entry point named in the manifest. In this build, it imports @oai/cua-repl and calls await cua_repl.launch(). Insert the proxy environment settings after the import and before that launch call:

    #!/usr/bin/env node
import * as cua_repl from "@oai/cua-repl";

// Temporary workaround: use your own local HTTP/mixed proxy port.
Object.assign(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",
});

try {
  await cua_repl.launch();
} catch (error) {
  const error_message =
    error instanceof Error ? error.message : String(error);
  console.error(`cua_repl could not start: ${error_message}`);
  process.exitCode = 1;
}

    The inspected launch() implementation copies process.env into the spawned backend's environment. This places the proxy variables into the child process at startup, including NODE_USE_ENV_PROXY. No trusted-service, approval, certificate-validation, or other security settings were changed.

    After applying the patch, fully exit and reopen Codex, keeping the local proxy running.

    Verification

    The syntax check passed. A separate launcher test confirmed that all seven settings reached a spawned child process; that test alone was not treated as proof of a browser fix.

    After restarting Codex, actual operations through the official Chrome plugin also passed:

    1. Connected to Chrome and listed existing tabs.
    2. Opened https://example.com/ and read its accessibility content.
    3. Clicked “Learn more”.
    4. Reached https://www.iana.org/help/example-domains and read its content.
    5. Closed the test tab.

    The earlier nodeRepl.fetch request failed did not recur during these checks.

    This is still a local workaround. Runtime/plugin updates can replace the patched file or select another runtime directory. Preserve the new version's launcher and add only the small environment block after checking its structure; do not copy an entire older launcher over a newer one. To undo, remove the added block or restore the matching backup.

    A stable, documented user proxy/environment override would avoid repeated edits to either plugin-generated configuration or bundled runtime files after updates.

  6. yizhaozhang11 commented on Sep 14, 2026

    @yizhaozhang11
    yizhaozhang11
    on Sep 14, 2026 – with ChatGPT Codex Connector

    Adding an independent Windows in-app browser verification of the September 12 workaround, tested September 14.

    Environment: Windows MSIX 26.908.4834.0, unified-computer-use 26.908.40834, bundled Node v24.20.0.

    Before the change, a signed-in website worked manually in the in-app browser, but cua.getState() repeatedly returned empty browser lists and nodeRepl.fetch request failed after about 21 seconds. The GUI was explicitly configured to use a local HTTP proxy; a connection snapshot during reproduction showed the CUA backend making direct external port-443 connections/attempts instead.

    A separate, unauthenticated probe to the browser identity endpoint using the same bundled Node produced:

    Configuration Result
    Direct 10-second timeout
    Proxy variables only 10-second timeout
    Proxy variables plus NODE_USE_ENV_PROXY=1 HTTP 403 in about 0.61 seconds

    The 403 establishes transport reachability only, not successful authentication.

    After backing up the actual bin/cua-repl.mjs entry point referenced by the active manifest, we applied the same seven environment settings from the linked comment, using the existing local proxy, and fully restarted the app.

    Actual post-restart verification: a connection snapshot showed 15 established TCP connections from the new CUA backend, all to the local proxy. Through the official CUA tool, browser discovery succeeded, an in-app tab opened the signed-in site, and its accessibility content was read successfully. The login session was preserved.

    One remaining observation: the first post-restart attempt reported Unable to load browser request-header policy. Retry the browser command.; retrying succeeded. No policy, trusted-service, or certificate checks were bypassed.

    This confirms the workaround for in-app-browser discovery/navigation/reading on this installation, beyond the Chrome verification above. A supported proxy/environment setting that survives runtime updates would help avoid patching bundled launchers.

  7. Yy-9519 commented on Sep 16, 2026

    @Yy-9519
    Yy-9519
    on Sep 16, 2026

    Windows Codex 无法控制 Chrome：代理修复记录

    故障现象

    Chrome 和 ChatGPT 扩展已安装，但 Codex 读取浏览器状态或列出标签页时，约 21 秒后报错：

    nodeRepl.fetch request failed

    本机定位结果

    读取运行中进程的实际环境后发现：

    • .codex/.env 已配置 HTTP/HTTPS 代理。
    • Codex app-server 收到了这些代理变量。
    • CUA 浏览器控制进程及其启动的 node_repl 没有收到。
    • 失败期间，node_repl 出现公网 443 连接持续处于 SYN_SENT 的情况。

    因此，本机问题定位在浏览器控制进程的代理环境传递上；具体是哪一层过滤或未传递变量，尚未完全确认。

    修复方式

    先备份当前版本实际使用的 CUA 启动文件，再在启动 node_repl 的 spawn(..., { env: ... }) 中加入：

    NODE_USE_ENV_PROXY: "1",
HTTP_PROXY: "http://127.0.0.1:7897",
HTTPS_PROXY: "http://127.0.0.1:7897",
http_proxy: "http://127.0.0.1:7897",
https_proxy: "http://127.0.0.1:7897",
NO_PROXY: "localhost,127.0.0.1,::1",
no_proxy: "localhost,127.0.0.1,::1",

    注意：

    • 7897 是本机 HTTP/mixed 代理端口，其他电脑应按实际端口调整。
    • 保留原有环境变量、trusted-service 和权限设置。
    • 不需要关闭沙箱、开启危险模式或重装扩展。

    本机修改文件为：

    C:\Users\Administrator\AppData\Local\OpenAI\Codex\runtimes\cua_node\6f12e0ef1c6e5061\bin\node_modules\@oai\cua-repl\dist\lib\js\oai_js_cua_repl\src\launch.js

    不同版本的路径和文件名可能不同，不能直接照抄。

    完成修改和语法检查后，完全退出并重启 Codex。

    修复验证

    重启后实际验证通过：

    1. Chrome provider 发现成功。
    2. listTabs 成功，耗时约 0.66 秒。
    3. 打开并读取 https://example.com/ 成功。
    4. 点击 “Learn more” 成功。
    5. 读取跳转后的 IANA 页面成功。

    这验证了真实浏览器操作，不只是代理端口或独立网络探测通过。

    为什么只在 .codex/.env 加 NODE_USE_ENV_PROXY=1 没用？

    做过排除补丁干扰的对照测试：

    1. 在已有完整代理配置的 .env 中加入 NODE_USE_ENV_PROXY=1。
    2. 将 launch.js 恢复原版。
    3. 完全退出并重启 Codex。
    4. 再次读取运行中进程环境并测试浏览器。

    结果：

    进程 代理变量 NODE_USE_ENV_PROXY
    app-server 已收到 1
    CUA / node_repl 未收到 未收到

    浏览器再次在约 21.98 秒后报 fetch 错误。

    所以，不能简单说这个变量“无效”：本机测试表明，它没有通过 .env 传入需要它的浏览器控制进程。直接在启动子进程时注入代理环境，才是本次验证有效的方式。

    失败后已恢复之前有效的启动补丁和测试前的 .env。恢复后的文件仍需重启 Codex 才能生效。

    Codex 更新后的注意事项

    这是临时绕过方案，不是官方持久配置接口。

    Codex 更新可能覆盖补丁，或改用新的运行时目录，导致修复失效；不是每次更新都一定失效。

    更新后若问题复现：

    1. 重新确认当前实际使用的启动文件。
    2. 检查代理补丁是否仍在。
    3. 如需重新修改，先备份新版本文件。
    4. 只补入代理环境设置，不要用旧版整份文件覆盖新版文件。
    5. 重启后重新验证标签列表、页面读取和链接点击。

    回滚时，恢复同版本的原文件备份，再重启 Codex。

    参考

    #44364 (comment)

    该 issue 使用旧版本 launch.mjs；本机使用的是运行时包内的 launch.js，应以实际启动链路为准。

  8. zxq520921-maker commented on Sep 16, 2026

    @zxq520921-maker
    zxq520921-maker
    on Sep 16, 2026

    Windows Codex 无法控制Chrome：代理修复记录

    故障现象

    Chrome 和 ChatGPT 扩展已安装，但 Codex 读取浏览器状态或列出标签页时，约 21 秒后报错：

    nodeRepl.fetch request failed

    本机定位结果

    读取运行中进程的实际环境后发现：

    • .codex/.env已配置HTTP/HTTPS 代理。
    • Codex app-server 收到了这些代理变量。
    • CUA 浏览器控制进程及其启动的node_repl没有收到。
    • 失败期间， node_repl出现公网443 连接持续处于SYN_SENT的情况。

    因此，本机问题定位在浏览器控制进程的代理环境传递上；具体是哪一层过滤或未传递变量，尚未完全确认。

    修复方式

    先备份当前版本实际使用的 CUA 启动文件，再在启动 node_repl 的 spawn(..., { env: ... }) 中加入：

    NODE_USE_ENV_PROXY: "1",
    HTTP_PROXY: "http://127.0.0.1:7897",
    HTTPS_PROXY: "http://127.0.0.1:7897",
    http_proxy: "http://127.0.0.1:7897",
    https_proxy: "http://127.0.0.1:7897",
    NO_PROXY: "localhost,127.0.0.1,::1",
    no_proxy: "localhost,127.0.0.1,::1",
    注意：

    • 7897是本机HTTP/mixed 代理端口，其他电脑应按实际端口调整。
    • 保留原有环境变量、trusted-service 和权限设置。
    • 不需要关闭沙箱、开启危险模式或重装扩展。

    本机修改文件为：

    C:\Users\Administrator\AppData\Local\OpenAI\Codex\runtimes\cua_node\6f12e0ef1c6e5061\bin\node_modules\@oai\cua-repl\dist\lib\js\oai_js_cua_repl\src\launch.js

    不同版本的路径和文件名可能不同，不能直接照抄。

    完成修改和语法检查后，完全退出并重启Codex。

    修复验证

    重启后实际验证通过：

    1. Chrome provider 发现成功。
    2. listTabs成功，耗时约0.66 秒。
    3. 打开并读取https://example.com/成功。
    4. 点击“Learn more” 成功。
    5. 读取跳转后的IANA 页面成功。

    这验证了真实浏览器操作，不只是代理端口或独立网络探测通过。

    为什么只在 .codex/.env 加 NODE_USE_ENV_PROXY=1 没用？

    做过排除补丁干扰的对照测试：

    1. 在已有完整代理配置的.env中加入NODE_USE_ENV_PROXY=1 。
    2. 将launch.js恢复原版。
    3. 完全退出并重启Codex。
    4. 再次读取运行中进程环境并测试浏览器。

    结果：

    进程 代理变量 NODE_USE_ENV_PROXY
    应用服务器 已收到 1
    CUA / node_repl 未收到 未收到
    浏览器再次在约21.98 秒后报fetch 错误。

    所以，不能简单说这个变量“无效”：本机测试表明，它没有通过 .env 传入需要它的浏览器控制进程。直接在启动子进程时注入代理环境，才是本次验证有效的方式。

    失败后已恢复之前有效的启动补丁和测试前的.env 。恢复后的文件仍需重启Codex 才能生效。

    Codex 更新后的注意事项

    这是临时绕过方案，不是官方持久配置接口。

    Codex 更新可能覆盖补丁，或改用新的运行时目录，导致修复失效；不是每次更新都一定失效。

    更新后若问题复现：

    1. 重新确认当前实际使用的启动文件。
    2. 检查代理补丁是否仍在。
    3. 如需重新修改，先备份新版本文件。
    4. 只补入代理环境设置，不要用旧版整份文件覆盖新版文件。
    5. 重启后重新验证标签列表、页面读取和链接点击。

    回滚时，恢复同版本的原文件备份，再重启Codex。

    参考

    #44364 (comment)

    该 issue 使用旧版本 launch.mjs；本机使用的是运行时包内的 launch.js，应以实际启动链路为准。

    2026-9-26 The issue has been successfully resolved.

  9. arthurx188-eng commented on Sep 18, 2026

    @arthurx188-eng
    arthurx188-eng
    on Sep 18, 2026 – with ChatGPT Codex Connector

    Additional confirmed Windows case (anonymized):

    Environment:

    • Windows 11 x64
    • ChatGPT/Codex desktop About version: 26.908.70816 (released 2026-09-15)
    • v2rayN 7.17.0 as the local proxy client
    • Official ChatGPT/Codex Chrome extension enabled

    Observed failure with TUN disabled:

    • In-app Browser failed to open/read pages
    • @chrome could not list existing Chrome tabs
    • Both paths returned nodeRepl.fetch request failed

    There was also an initial Native Messaging registration problem:

    • The manifest existed at %LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json
    • extension-host.exe existed at the path referenced by the manifest
    • But HKCU\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension was missing
    • Manually creating that key to point to the manifest removed the "Windows native host registry key does not exist" error, but browser operations still failed with nodeRepl.fetch request failed

    Final working result:

    1. Keep the repaired Native Messaging registry entry in place
    2. Enable TUN mode in v2rayN
    3. Restart Codex
    4. In-app Browser successfully opened and read a site
    5. @chrome successfully listed all currently open Chrome tabs

    Turning on TUN was the decisive step for restoring the browser-control transport in this case. This provides another reproduction with v2rayN (not Clash) and shows that both the in-app browser and Chrome-backed browser control can be affected by the same proxy-routing issue.

  10. railgun20001 commented on Sep 18, 2026

    @railgun20001
    railgun20001
    on Sep 18, 2026

    Additional Windows recurrence after a desktop/runtime update, reported on September 18, 2026 with the user's authorization.

    Environment:

    • Microsoft Store package OpenAI.Codex: 26.915.3509.0
    • Bundled unified-computer-use plugin: 26.915.31029
    • Existing local HTTP proxy enabled in Windows and listening on loopback

    Observed behavior:

    • The official CUA tool failed to create a Chrome tab with nodeRepl.fetch request failed after approximately 21 seconds.
    • Resetting the CUA JavaScript session and retrying browser inventory produced the same error. No page read or click succeeded in these attempts.
    • A previous September 15 local launcher patch had been followed by successful Chrome opening, reading, link clicking, and tab cleanup. The current plugin manifest now selects a different runtime directory, whose @oai/cua-repl/bin/cua-repl.mjs entry point has no proxy block.
    • The current generated MCP definition has no HTTP_PROXY / HTTPS_PROXY / NO_PROXY / NODE_USE_ENV_PROXY entries. Its env_vars list contains only CODEX_WINDOWS_REGISTERED_CORE. This is configuration evidence; we did not inspect the live helper's process environment in this recurrence.

    Recovery performed so far:

    • Backed up the current-version entry point and restored the seven proxy environment settings before cua_repl.launch(), using the already-running local proxy.
    • Preserved the original launch/error-handling code and all existing identity, certificate, trusted-service, and permission checks.
    • Syntax checking and an isolated child-environment inheritance check passed. An unauthenticated proxy connectivity check to example.com returned HTTP 200.
    • A full desktop restart and actual Chrome page-operation retest are still pending. These checks do not establish restored browser control or successful authenticated browser-backend connectivity. TUN state was not independently verified in this recurrence.

    The update selected a new unpatched runtime, making the prior local workaround ineffective. Could maintainers provide a supported proxy/environment overlay that is merged before the managed CUA process starts and survives desktop/plugin/runtime updates? A version-specific source patch requires repeated manual maintenance. The configuration-watcher workaround discussed in #42454 also has a startup race and is not equivalent to a supported persistent override.

    No credentials, private URLs, browser contents, account/task identifiers, raw logs, or user-specific filesystem paths are included.

  11. Thymos2027 commented on Sep 19, 2026

    @Thymos2027
    Thymos2027
    on Sep 19, 2026 – with ChatGPT Codex Connector

    I can reproduce the same proxy-handling failure on a newer Windows build and Codex package.

    Environment

    • Windows 11 Pro 10.0.26200
    • Codex AppX package: 26.915.3509.0
    • Bundled Codex CLI: 0.155.0-alpha.9
    • Local HTTP proxy: 127.0.0.1:7890 (listener confirmed active)
    • Windows system proxy: enabled and pointing to 127.0.0.1:7890
    • HTTP_PROXY, HTTPS_PROXY, and ALL_PROXY: set to http://127.0.0.1:7890
    • NO_PROXY: includes localhost,127.0.0.1,::1
    • No active Clash/Mihomo/Wintun adapter was detected, so TUN was not part of this reproduction.

    Reproduction

    A minimal browser inventory call fails before any website navigation:

    await cua.getState();

    After approximately 21–22 seconds:

    apps: []
browsers: []
Browsers: Error: nodeRepl.fetch request failed

    The stack ends in Pipe.onStreamRead.

    The failure persisted after:

    1. setting the user/system proxy;
    2. setting the proxy environment variables listed above;
    3. temporarily setting WinHTTP to the same proxy endpoint;
    4. fully exiting and restarting Codex Desktop.

    WinHTTP was reset to Direct access (no proxy server) after the test. The first post-restart cua.getState() call failed identically from a newly created runtime temp directory, so this was not an old Node REPL process or stale kernel.

    This does not prove that the runtime is necessarily making a direct external connection—the failure happens during browser discovery, before navigation—but it does show that the standard Windows proxy paths and proxy environment variables did not resolve the Browser Use control-path failure in this configuration.

    No private URLs, credentials, account identifiers, proxy node details, or session logs are included.

  12. Hello-QM commented on Sep 20, 2026

    @Hello-QM
    Hello-QM
    on Sep 20, 2026

    Verified Linux reproduction and proxy-only workaround (2026-09-20)

    Adding a Linux case to this issue because the proxy-inheritance failure and successful workaround closely match the Windows reports above. This is a local workaround, not an official fix or a claim that every nodeRepl.fetch failure has the same cause.

    Environment

    • Linux x86_64.
    • Installed desktop package: chatgpt 26.915.31945.
    • Bundled CLI: codex-cli 0.155.0-alpha.9.2.
    • Bundled CUA Node: v24.21.0.
    • Chrome with the ChatGPT extension; an existing loopback HTTP proxy was available.

    Failure and evidence

    Chrome discovery could succeed, but tab enumeration and cua.getState() failed after approximately 30 seconds with nodeRepl.fetch request failed. An empty browser list accompanied by this error was an inventory failure, not evidence that Chrome was closed.

    Read-only inspection of the running processes showed:

    • The Chrome native-messaging host already had proxy variables, and extension-side chat could receive replies.
    • The separate CUA launcher and its node_repl backend did not have HTTP_PROXY, HTTPS_PROXY, or NODE_USE_ENV_PROXY.
    • The affected backend made direct external connection attempts.
    • Using the same bundled Node for an unauthenticated connectivity comparison, direct access failed with ETIMEDOUT; explicit use of the existing HTTP proxy returned HTTP 403 in about 1.3 seconds. The 403 proves transport reachability only, not successful authentication or browser control.

    Important failed attempt: generated plugin configuration

    Adding proxy variables to the cached unified-computer-use/<version>/.mcp.json was not durable on this installation. After the desktop app restarted, the file matched its original contents again, and the new CUA backend still had no proxy environment. Editing that generated file alone did not fix the issue.

    Workaround that was actually verified

    Resolve the active CUA entry point from the current plugin manifest/process arguments rather than assuming an old scripts/launch.mjs path. On this Linux installation it was:

    /usr/lib/chatgpt/resources/cua_node/lib/node_modules/@oai/cua-repl/bin/cua-repl.mjs

    Back up that exact current-version file first. Before its existing await cua_repl.launch() call, add proxy defaults matching the already-running local HTTP proxy. The defaults below preserve explicitly supplied settings; 7890 is an example and must match the machine's actual proxy port.

    process.env.NODE_USE_ENV_PROXY ??= "1";
process.env.HTTP_PROXY ??= process.env.http_proxy ?? "http://127.0.0.1:7890";
process.env.HTTPS_PROXY ??= process.env.https_proxy ?? process.env.HTTP_PROXY;
process.env.http_proxy ??= process.env.HTTP_PROXY;
process.env.https_proxy ??= process.env.HTTPS_PROXY;
process.env.NO_PROXY ??= process.env.no_proxy ?? "localhost,127.0.0.1,::1,0.0.0.0,*.local,100.64.0.0/10,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16";
process.env.no_proxy ??= process.env.NO_PROXY;

    Keep the original imports, launch call, error handling, trusted-service configuration, surface selection, and permissions unchanged. This installation required administrator authorization to edit the system-owned entry point; file ownership/permissions were not loosened.

    Then fully exit and reopen the desktop application. Closing a window or installing the patch while leaving the old background process alive is insufficient: we explicitly observed an older backend remaining alive without the new environment until the full restart.

    Verification after the full restart

    • The patch remained present and the original-file backup existed.
    • A newly started CUA node_repl backend had both HTTP(S) proxy variables and NODE_USE_ENV_PROXY=1.
    • The supported cua.getState() call returned the real Chrome extension browser and its existing tab, without the previous fetch error.
    • A subsequent cua.listTabs({ browser: currentChromeId }) returned the existing tab and title successfully in 581 ms. The browser ID was obtained from the live inventory, not hardcoded.
    • Separate staging checks passed: JavaScript syntax, exact preservation of the original launch/error-handling code, real launcher-to-child environment inheritance, preservation of existing proxy settings, and unchanged enabled surfaces/untrusted-environment allowlist.

    This verifies recovery of browser discovery and tab/title reads on this machine. Navigation, clicking, form submission, and native desktop control were not tested in the final verification. It is not a claimed fix for every unrelated trusted-Node crash.

    No extension reinstall, browser-profile reset, cookie deletion, sandbox disabling, certificate bypass, identity/request-header-policy patch, or permission expansion was needed. No new TUN/network-wide setting was introduced for this repair.

    Limitations and upstream request

    • This patches an installed runtime entry point. Desktop/runtime updates may replace it or select a different path. Re-check the current manifest after updates; do not overwrite a newer launcher with an older whole-file backup.
    • Roll back by restoring the matching original entry-point backup and fully restarting the desktop app.
    • Please provide a supported proxy-environment overlay for managed cua_repl that survives startup regeneration and updates, and diagnostics that distinguish backend proxy/identity-request failure from extension installation problems.

    This report intentionally omits account identifiers, private tab titles/URLs, local usernames/home paths, task IDs, credentials, screenshots, and raw logs. Related same-version symptom report: #46609; environment-overlay discussion: #42454.

  13. zhenronghua commented on Sep 22, 2026

    @zhenronghua
    zhenronghua
    on Sep 22, 2026

    After trying the above method, the problem still persists. Have any users successfully resolved the issue of nodeRepl.wait request failure

  14. vaeccc commented on Sep 28, 2026

    @vaeccc
    vaeccc
    on Sep 28, 2026 – with ChatGPT Codex Connector

    Confirmed workaround on Windows with FlClash / Codex Desktop 26.924.2738.0.

    Environment:

    • Windows
    • Codex Desktop: 26.924.2738.0
    • Chrome + official Browser Use extension
    • FlClash
    • Local proxy: 127.0.0.1:7890

    Symptoms:

    • Chrome extension installed and enabled
    • Native Messaging Host and current node/node_repl paths verified
    • Computer Use worked (window enumeration, accessibility tree, screenshots)
    • Browser Use failed at chrome.tabs.list() with:
    nodeRepl.fetch request failed

    I also confirmed that proxy environment variables added manually were not a durable fix in this build: the Desktop startup reconciliation rewrote the relevant Node REPL proxy allowlist, so the Browser Use/CUA child process did not reliably inherit the proxy settings.

    What fixed it:

    1. Run FlClash with administrator privileges.
    2. Enable Virtual Network Adapter (FlClash's TUN mode).
    3. Keep the proxy node active.
    4. Fully quit Codex Desktop (including tray/background processes).
    5. Fully close Chrome.
    6. Start FlClash with TUN enabled.
    7. Start Chrome.
    8. Start Codex Desktop.
    9. Retry Chrome Browser Use.

    After enabling FlClash's virtual network adapter / TUN mode and restarting Chrome + Codex, Chrome Browser Use started working and the nodeRepl.fetch request failed error disappeared.

    This suggests that, at least on this setup, TUN works because Browser Use traffic is routed at the system/network layer instead of depending on the CUA/node_repl child process inheriting HTTP_PROXY / HTTPS_PROXY.

    This does not imply every nodeRepl.fetch request failed has the same cause, but for Windows users running Clash/FlClash it is worth testing TUN before modifying the MSIX/app.asar or reinstalling Windows.

  15. kyee179 commented on Sep 29, 2026

    @kyee179
    kyee179
    on Sep 29, 2026 – with ChatGPT Codex Connector

    Verified follow-up: newer Windows builds use cua-repl.mjs, not launch.mjs

    I reproduced and fixed the same proxy-handling failure on a newer Codex Desktop/browser-plugin layout. This follow-up documents the changed launcher structure and a minimal workaround without publishing machine-specific configuration.

    Symptom

    Before modification, the live controller returned:

    Browsers: Error: nodeRepl.fetch request failed

    Browser inventory/control was unavailable even though Codex, Chrome, the official extension, and an existing local HTTP/mixed proxy were running.

    Evidence and root cause

    The diagnostic chain was:

    1. The existing local proxy was listening and reachable.
    2. A direct HTTPS fetch() using Codex's bundled Node runtime failed with TypeError.
    3. The same runtime successfully received an HTTP response when launched with Node's environment-proxy support enabled and pointed at the local proxy.
    4. The live Codex browser controller independently reproduced nodeRepl.fetch request failed.

    This isolates the failure to proxy configuration for the managed Node/NodeREPL transport, rather than Chrome discovery or the native extension connection.

    Packaging difference in the newer build

    This build no longer contains the earlier versioned scripts/launch.mjs.

    The generated plugin manifest launches the bundled Node executable with:

    <current-cua-runtime>\node_modules\@oai\cua-repl\bin\cua-repl.mjs

    The installed @oai/cua-repl implementation subsequently spawns the executable from CUA_REPL_NODE_REPL_PATH and copies process.env into the child's environment.

    Minimal workaround for this launcher layout

    First, create a matching-version backup beside cua-repl.mjs. Then add the following immediately after the import and before cua_repl.launch(), replacing the placeholder with the existing local HTTP/mixed proxy URL:

    const localProxy = "<local-http-proxy-url>";

Object.assign(process.env, {
  NODE_USE_ENV_PROXY: "1",
  HTTP_PROXY: localProxy,
  HTTPS_PROXY: localProxy,
  http_proxy: localProxy,
  https_proxy: localProxy,
  NO_PROXY: "localhost,127.0.0.1,::1",
  no_proxy: "localhost,127.0.0.1,::1",
});

    Why this works: the wrapper sets the variables before spawning node_repl.exe, so the new child sees NODE_USE_ENV_PROXY=1 at process startup. Setting that variable later inside an already-running Node process did not make that process's global fetch() begin using the proxy.

    I restored the generated plugin .mcp.json to its original bytes afterward, leaving only the small launcher addition. This avoids relying on edits to generated manifest data.

    End-to-end validation

    After the controller reloaded:

    1. Browser inventory returned successfully without nodeRepl.fetch.
    2. Chrome launched and its official extension connected.
    3. Codex created a fresh Chrome tab on a public test page.
    4. Codex read the page's accessibility tree.
    5. Codex closed only the temporary verification tab.
    6. node --check cua-repl.mjs passed.
    7. The launcher diff contained only additions and no removed lines.

    This verifies actual Codex-to-Chrome control, not merely a standalone network probe.

    Rollback and limitations

    • Roll back by restoring the backup from the same runtime version.
    • Do not copy an older launcher wholesale into a newer runtime.
    • A Codex/plugin update may replace the versioned runtime and remove the workaround.
    • Substitute the user's own local proxy URL; do not hard-code someone else's endpoint.
    • This remains a local workaround. A supported persistent override or reliable Windows system-proxy integration is preferable.

    Suggested upstream fix

    Please provide one of:

    • automatic Windows system-proxy support;
    • a documented persistent proxy configuration;
    • or a stable user-owned environment override merged into generated runtime configuration and preserved across updates.

    Original prompt used for the investigation

    can you try to solve the error 'noderepl.fetch request failed' based on this :#44364 . Please actually investigate and fix the issue of Codex controlling Chrome on my Windows machine, and don't just give general suggestions. I authorize you to perform read-only diagnostics on your local machine, and once you have supporting evidence, back up and minimize modifications to the current Codex browser controller launcher so that it uses my existing local proxy. Do not output account tokens, personal page content, or other sensitive configurations. Do not delete files directly.

  16. JackHuang90 commented on Sep 30, 2026

    @JackHuang90
    JackHuang90
    on Sep 30, 2026 – with ChatGPT Codex Connector
    Author

    Update (September 30, 2026): project-scoped proxy configuration verified on the native node_repl.exe layout

    On my current Windows installation, Chrome control now works after a full Codex restart using a project-level configuration override, without patching the active launcher/runtime source for this repair. This supersedes my earlier launcher-edit instructions for the specific layout described below.

    Versions actually tested

    Component Observed version/layout
    Windows desktop package OpenAI.Codex 26.928.1915.0
    Browser plugin / BROWSER_USE_CODEX_APP_VERSION 26.928.20755
    Bundled Node v24.21.0
    Active MCP server node_repl, directly launching the bundled node_repl.exe

    The desktop package version and Browser plugin version are different identifiers. I have verified this combination only, not an entire version range.

    Why the older workaround stopped applying

    In this installation, the active MCP definition launches:

    %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<current-runtime-id>\bin\node_repl.exe

    The old launch.mjs / cua-repl.mjs wrapper is no longer the active entry point for this server, so editing that older wrapper does not affect the current browser-control process.

    Adding the proxy entries directly under [mcp_servers.node_repl.env] in the user-level %USERPROFILE%\.codex\config.toml was also insufficient here: they were absent after desktop startup regenerated the managed server configuration, and browser control still failed.

    Configuration-only workaround

    In the trusted project/task directory used by the Codex conversation, create or edit:

    <project-root>\.codex\config.toml

    Merge this section into the existing file; do not replace unrelated project settings or create a duplicate TOML table:

    [mcp_servers.node_repl.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"

    Replace 7890 with the actual port of your running HTTP/mixed proxy. Keep the existing project trust and MCP security settings.

    The project override contains only environment settings. It leaves the executable path, Node path, and browser-service paths under desktop management, so it does not pin the server to an older runtime/plugin version.

    Keep the proxy running, fully exit Codex including background processes, then reopen the conversation in that same project directory.

    Verification after restart

    • The project configuration remained present, although the user-level managed configuration still had no explicit proxy entries.
    • Running codex mcp get node_repl --json from the project directory showed the merged proxy settings alongside the current desktop-managed executable/browser settings. This verifies effective configuration, not an independent inspection of the live process environment.
    • Through the official Browser plugin, Codex connected to Chrome, opened https://example.com/, and read its accessibility content.
    • It clicked the visible “Learn more” link, reached https://www.iana.org/help/example-domains, and read the destination content.
    • It captured the resulting page and successfully closed the temporary test tab.
    • The previous fetch failure did not recur during these actual browser operations.

    Scope, updates, and rollback

    • This override applies to the trusted project directory where it is installed. Other project directories do not automatically inherit it.
    • This is a locally verified workaround, not confirmation of an upstream fix. The current retest did not independently verify TUN was disabled, so it should not be treated as a fresh TUN-off comparison.
    • It survived the tested desktop restart. Survival across a future desktop/plugin update has not yet been tested.
    • After an update, first check the effective node_repl configuration from the same project directory and repeat real Chrome navigation/reading/clicking. If the server name or startup architecture changes, reassess the active configuration instead of copying an older launcher over new files.
    • To undo, remove only these project-level proxy overrides (preserving any pre-existing settings), then fully restart Codex.

    Please document whether project-scoped environment overrides for this managed server are supported, and provide a persistent user-level proxy override that desktop startup preserves for conversations across projects.

  17. hardstuding commented on Sep 30, 2026

    @hardstuding
    hardstuding
    on Sep 30, 2026

    Additional root-cause details from a Windows repro (Codex desktop 26.928.1915.0, cua-node runtime 0.0.27, unified-computer-use 26.928.20755; same behavior on 26.924):

    1. The failing request is made by node_repl.exe itself (authenticated_fetch.rs, reqwest). codex.exe includes a Windows system-proxy fallback (it reads Internet Settings\ProxyServer; its logs show system_proxy_fallback: true), but node_repl.exe contains no Windows system-proxy lookup, so it only honors HTTP(S)_PROXY environment variables.
    2. Those variables never reach it. MCP stdio servers get an allowlisted environment (PATH, TEMP, USERPROFILE, ...). The desktop app regenerates cua_repl's env in the plugin's .mcp.json on every launch, and writes mcp_servers.node_repl with mergeStrategy replace. Plugin MCP overrides in config.toml accept only enabled/tools-style fields, so a user cannot add env or env_vars persistently.
    3. On a network where chatgpt.com is reachable only through a local proxy, every Chrome operation waits about 21 s (the Windows TCP connect timeout) and fails with nodeRepl.fetch request failed. The in-app browser keeps working. curl --noproxy '*' https://chatgpt.com times out at 21.05 s; through the local proxy it responds in under 1 s.
    4. Driving cua_repl directly over MCP stdio with cua.getState(): without proxy variables it always fails with nodeRepl.fetch request failed (every Chrome attempt in my session logs since 2026-09-09 failed this way). With HTTPS_PROXY set, Chrome (extension) was discovered in 7 of 12 fresh sessions; every remaining failure was the Statsig timeout in item 5. Setting the variables in %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node_modules\@oai\cua-repl\bin\cua-repl.mjs works, but the runtime directory is replaced on update (here on 2026-09-27 and again on 2026-09-30), so the fix is lost.
    5. Secondary issue once the proxy works: Statsig initialization downloads about 5.3 MB from ab.chatgpt.com/v1/initialize (uncompressed even with Accept-Encoding: gzip) with a 10 s timeout. On slower links it fails with Unable to load browser request-header policy. Timed-out requests do not appear to be aborted on the host side (connections kept downloading for 30–48 s after the timeout), so retries in the same kernel compete for bandwidth and keep failing.

    Suggested fixes: give node_repl the same proxy resolution as codex.exe (environment variables plus the Windows system proxy), or forward HTTP(S)_PROXY/NO_PROXY into MCP server environments; allow a persistent user override for plugin MCP env; and make the Statsig initialization timeout and abort behavior tolerant of slow links.

    Related: #22623, #23504, #46386.

  18. swei99386-alt commented on Sep 30, 2026

    @swei99386-alt
    swei99386-alt
    on Sep 30, 2026

    Confirming on Windows 11, Codex desktop 26.928.1915.0 / unified-computer-use 26.928.20755, Clash Verge on 127.0.0.1:7897, TUN off — same root cause as @hardstuding describes above. On this machine the active Chrome path is still cua_repl (the generated node_repl entry has its browser/Chrome instructions blanked), so a project-level [mcp_servers.node_repl.env] override does not reach it.

    Two additions that may help whoever fixes this:

    1. The desktop app already forwards proxies for another bundled MCP server. The code-review plugin's MCP env includes HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY, SSL_CERT_FILE, NODE_EXTRA_CA_CERTS. Doing the same for the generated node_repl / cua_repl env_vars (currently only ["CODEX_WINDOWS_REGISTERED_CORE"]) would fix this.
    2. Isolated check: a standalone node_repl.exe with a minimal trusted service calling nodeRepl.fetch("https://chatgpt.com/backend-api/aura/identity") fails with nodeRepl.fetch request failed after 21.27 s without the variables, and returns 200 in 0.57 s with them.

    Config-only workaround that doesn't touch runtime files (lost on every desktop restart; re-apply, then open a new chat): append "HTTP_PROXY", "HTTPS_PROXY", "ALL_PROXY", "NO_PROXY" to env_vars of cua_repl in %USERPROFILE%\.codex\plugins\cache\openai-bundled\unified-computer-use\<version>\.mcp.json. Don't put an env table under [mcp_servers.cua_repl] in config.toml instead — Codex then fails to load its config (invalid transport).

  19. Hyacehila commented on Oct 1, 2026

    @Hyacehila
    Hyacehila
    on Oct 1, 2026

    Confirmed another Windows recurrence and recovery on October 1, 2026: desktop AppX 26.928.3736.0, unified-computer-use 26.928.31416, bundled Node v24.21.0, with the existing HTTP proxy running and Clash TUN disabled.

    The update selected a new runtime whose active @oai/cua-repl/bin/cua-repl.mjs entry lacked the previous proxy workaround. Before repair, official browser inventory failed with nodeRepl.fetch request failed after 21.53 seconds. After backing up that matching-version entry, reapplying only the proxy environment block, and a user-reported desktop restart, Chrome inventory succeeded. We then opened the public Example Domain page through the official Chrome extension, read its accessibility content, and successfully closed the test tab.

    This installation still uses the cua_repl wrapper path; we have not tested the project-level override reported for the direct node_repl.exe layout. Recovery here was after patch plus restart; a stock-entry restart control has not been performed, so restart alone has not been ruled out.

    Full measurements, three-repeat launcher controls, and limitations are in the evidence comment on #42454. The launcher controls show that the stock launcher can forward proxy settings when explicitly supplied, so they do not prove that launch() itself discards them.

    A supported proxy configuration that survives runtime updates is still needed.

  20. JackHuang90 commented on Oct 3, 2026

    @JackHuang90
    JackHuang90
    on Oct 3, 2026 – with ChatGPT Codex Connector
    Author

    Update — October 3, 2026: recovery confirmed; proxy settings must cover both browser MCP paths

    Chrome control is usable again after applying the workaround below. The post-repair recovery was confirmed by the affected user. This installation exposes both the newer direct node_repl Browser tool and the legacy cua_repl tool; configuring only one leaves conversations using the other path failing.

    Versions inspected

    • Windows Codex Desktop package: 26.930.3748.0
    • Browser / unified-computer-use plugins: 26.930.31428
    • Bundled CLI: 0.160.0
    • Bundled Node: v24.21.0
    • Active CUA runtime directory: 32a57e0f41f3a96a
    • Local HTTP/mixed proxy: http://127.0.0.1:7890

    These findings apply to the inspected installation; the runtime directory is not a stable path across updates.

    Why some conversations still failed

    The legacy tool reproduced:

    Browser 3: Error: nodeRepl.fetch request failed

    Chrome discovery worked, but tab retrieval failed. The active unified-computer-use manifest started node.exe with @oai/cua-repl/bin/cua-repl.mjs. Its env_vars contained only CODEX_WINDOWS_REGISTERED_CORE, and its explicit environment had no proxy settings. The current launcher also lacked the proxy block.

    Meanwhile, the newer direct node_repl Browser tool successfully opened a page, read its accessibility content, clicked a link, reached the destination, and closed the test tab. Both outcomes occurred in the same diagnostic conversation. A global [mcp_servers.node_repl.env] override therefore did not cover the separately launched legacy cua_repl backend.

    The inspected legacy launch() implementation copies process.env into its child backend environment. This is an omitted proxy configuration on that startup path, not evidence that launch() itself strips proxy variables.

    Workaround A: direct node_repl path, shared across projects

    On this installation, the bundled CLI reads system configuration from:

    %ProgramData%\OpenAI\Codex\config.toml

    With administrator privileges, merge the following into that file, preserving existing configuration:

    [mcp_servers.node_repl.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"

    The system-config path was checked against the matching CLI release's configuration loader. Effective node_repl configuration included these settings from six registered project directories and a directory with no project override. This checks configuration merging; it does not independently prove real browser operations in every project. The diagnostic project also retained its earlier project-level override.

    This leaves executable/runtime/browser-service paths under Desktop management. It does not require copying those versioned paths into the system configuration.

    Workaround B: legacy cua_repl path

    Follow the entry point in the active unified-computer-use .mcp.json, then back up that matching-version launcher. In the inspected build, it is:

    %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\32a57e0f41f3a96a\bin\node_modules\@oai\cua-repl\bin\cua-repl.mjs

    Insert only this block after import * as cua_repl from "@oai/cua-repl"; and before the existing try / await cua_repl.launch():

    Object.assign(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",
});

    Keep the original launch and error-handling code. The syntax check passed, a child-process probe verified inheritance of all seven settings, and comparison with the backup confirmed that only this block was added. The affected user subsequently confirmed Chrome control works.

    Use your own running HTTP/mixed proxy port. Fully exit and restart Codex so existing MCP processes pick up the changes; resetting just the JavaScript tool session does not restart the launcher.

    Scope and updates

    • The legacy launcher change applies to conversations/projects using that same runtime, without separate project edits.
    • Runtime updates can replace the patched launcher or select a new directory. Recheck the active manifest, back up the new file, and reapply only the environment block if necessary. Do not overwrite a new launcher with an entire old file.
    • The system configuration avoids pinning the newer backend to a runtime version, but its behavior across a future Desktop update has not been verified.
    • This latest retest did not independently check TUN status or perform a stock-launcher restart control.
    • No trusted-service, certificate-validation, request-header-policy, or approval settings were changed. To undo, remove only the added proxy settings/block or restore the matching launcher backup.

    A supported persistent proxy override for both managed backend paths would avoid repeated runtime edits and differences between conversations.

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 appbrowserbugSomething isn't workingconnectivityIssues involving networking or endpoint connectivity problems (disconnections)windows-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