Skip to content

Windows: Chrome control fails with nodeRepl.fetch request failed #44135

Open
Open
Windows: Chrome control fails with nodeRepl.fetch request failed#44135
Labels
appIssues related to the Codex desktop appbrowserbugSomething isn't workingwindows-osIssues related to Codex on Windows systems

Description

@gc8531517-sketch
gc8531517-sketch
opened on Sep 9, 2026

Chrome browser control fails on Windows with nodeRepl.fetch request failed.

Chrome was detected, but listing tabs failed. In-app browser tab listing succeeded in the same session. An attempt to open Edge through the control tool also failed.

Extension and native-host checks passed. Reinstalling the extension, restarting Windows and the app, and resetting the browser session did not resolve the issue. The app reports it is up to date.

Feedback ID: 01a07aca-9ad6-71d1-92ed-383061a55e95

Please advise on the underlying cause and a supported fix or workaround.

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
    on Sep 9, 2026

  2. github-actions commented on Sep 9, 2026

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

    @JackHuang90
    JackHuang90
    on Sep 10, 2026

    The same.

  4. wxdChinese commented on Sep 10, 2026

    @wxdChinese
    wxdChinese
    on Sep 10, 2026

    The same.

  5. JJjyJJ7F3 commented on Sep 10, 2026

    @JJjyJJ7F3
    JJjyJJ7F3
    on Sep 10, 2026

    The same.

  6. qsztt commented on Sep 10, 2026

    @qsztt
    qsztt
    on Sep 10, 2026

    the same

  7. Mark-Josh commented on Sep 10, 2026

    @Mark-Josh
    Mark-Josh
    on Sep 10, 2026

    The same.

  8. pengqiangQiao commented on Sep 10, 2026

    @pengqiangQiao
    pengqiangQiao
    on Sep 10, 2026

    the same

  9. East-Leo commented on Sep 10, 2026

    @East-Leo
    East-Leo
    on Sep 10, 2026

    The same: It detects Chrome configurations and extensions, but after about 21 seconds of attempting to read tabs, it still reports a "nodeRepl.fetch request failed" error, making it impossible to interact with the web pages.

  10. douxiaolong commented on Sep 11, 2026

    @douxiaolong
    douxiaolong
    on Sep 11, 2026

    所以有解决方案吗

  11. Mark-Josh commented on Sep 11, 2026

    @Mark-Josh
    Mark-Josh
    on Sep 11, 2026

    所以有解决方案吗
    目前看应该是开个Tun模式会好

  12. lfengwa2 commented on Sep 11, 2026

    @lfengwa2
    lfengwa2
    on Sep 11, 2026

    the same

  13. douxiaolong commented on Sep 11, 2026

    @douxiaolong
    douxiaolong
    on Sep 11, 2026

    所以有解决方案吗

    兄弟们，试一下这个，解决了我的问题#44364 (comment)

  14. kubernetes-dev commented on Sep 15, 2026

    @kubernetes-dev
    kubernetes-dev
    on Sep 15, 2026

    The same.

  15. tyljx commented on Sep 15, 2026

    @tyljx
    tyljx
    on Sep 15, 2026 – with ChatGPT Codex Connector

    For anyone hitting this on Windows behind a local HTTP proxy / Clash / mihomo / v2rayN: one important thing to check is Node 24's environment-proxy opt-in.

    Codex currently bundles Node 24.x for the browser/CUA runtime. Node's built-in fetch() does not automatically use HTTP_PROXY / HTTPS_PROXY unless environment proxy support is explicitly enabled with:

    setx NODE_USE_ENV_PROXY "1"
setx HTTP_PROXY "http://127.0.0.1:10808"
setx HTTPS_PROXY "http://127.0.0.1:10808"
setx ALL_PROXY "http://127.0.0.1:10808"
setx NO_PROXY "localhost,127.0.0.1,::1"

    Then fully exit Codex/ChatGPT and make sure ChatGPT.exe, node_repl.exe, and extension-host.exe are no longer running before restarting. setx only affects newly started processes.

    A useful diagnostic pattern is:

    • Browser Use works with TUN enabled.
    • It fails with TUN disabled with nodeRepl.fetch request failed.
    • HTTP_PROXY / HTTPS_PROXY are already present, but NODE_USE_ENV_PROXY is missing.

    In that case, enabling NODE_USE_ENV_PROXY=1 is worth testing before reinstalling Codex or changing WinHTTP settings.

    Also keep NO_PROXY=localhost,127.0.0.1,::1 so local browser/native-host RPC is not sent through the proxy.

    There is a more detailed Windows reproduction/workaround in #44364, including a verified launcher-level environment injection for cases where Codex's generated plugin runtime does not inherit the user's proxy environment.

  16. a1212a11 commented on Sep 15, 2026

    @a1212a11
    a1212a11
    on Sep 15, 2026

    Same issue here, still reproducible today (2026-09-15).

    On Windows 10, Codex Desktop's browser-control inventory always fails with nodeRepl.fetch request failed. It returns apps: [] and browsers: [] even though Chrome is running and the official Chrome extension side panel reports connected. The issue persists after restarting Chrome, the extension host, Codex, and the CUA bridge. HTTP and Responses WebSocket diagnostics are healthy after enabling respect_system_proxy = true; therefore this appears to be an internal CUA/node_repl bridge failure rather than a network or website issue. Multiple node_repl.exe and cua-repl.mjs child processes have been observed under the Codex app-server. Please advise how to reset/reinstall the browser-control bridge cleanly or collect a supported diagnostic bundle.

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

Error: nodeRepl.fetch request failed
    at ...\kernel.js:1595:16
    at ...\worker-runtime.js:396:5
    at ...\kernel.js:1871:11
    at Socket.<anonymous> (...\worker-runtime.js:434:9)

    Environment

    • Windows 10 Pro 64-bit, 10.0.19045, system language zh-CN
    • ChatGPT/Codex Desktop: 26.908.4834.0
    • Codex CLI diagnostic runtime: 0.154.0-alpha.6.2
    • CUA Node Runtime: a708e72b10c27b59
    • Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg
    • Chrome Native Host: com.openai.codexextension
    • Browser-control service: @oai/cua-repl
    • System proxy: Clash on 127.0.0.1:7897, respect_system_proxy = true

  17. a1212a11 commented on Sep 15, 2026

    @a1212a11
    a1212a11
    on Sep 15, 2026

    Follow-up with a narrowed-down root cause on my setup (Windows 10 19045, Codex Desktop 26.908.4834.0, CUA runtime a708e72b10c27b59, local Clash HTTP proxy on 127.0.0.1:7897).

    Confirmed: enabling the proxy client's TUN mode makes browser control pass immediately (browser inventory, tab listing, navigation all work). Disabling TUN reproduces nodeRepl.fetch request failed / Unable to load browser request-header policy. Same pattern as #44364.

    Why the launch.mjs / cua-repl.mjs proxy patches from #44364 / #44801 do not help on this version:

    1. On 26.908.x there is no launch.mjs; the bridge is started from .mcp.json running @oai/cua-repl/bin/cua-repl.mjs.
    2. launch() spawns node_repl.exe with env: { ...process.env, ... } (full inheritance, no allowlist filtering), so injecting HTTP_PROXY / HTTPS_PROXY / NODE_USE_ENV_PROXY before launch() does reach node_repl.exe. NODE_REPL_UNTRUSTED_ENV_ALLOWLIST only controls what untrusted REPL cells can see; it does not affect the host's network layer.
    3. node_repl.exe is a ~35 MB OpenAI-signed native executable, not a Node runtime (--version prints no Node version; it separately spawns node.exe v24.20.0 for kernel.js / trusted-worker.js). So NODE_USE_ENV_PROXY has no effect on it.
    4. The Statsig / request-header-policy fetch (https://ab.chatgpt.com/v1/...) is issued via networkOverrideFunc: (url, init) => e.fetch(url, init), and e.fetch is authenticatedFetch, which serializes the request over IPC (type: "authenticated_fetch") to the node_repl.exe host. The native host performs the actual HTTP request.
    5. That native host appears to ignore both HTTP_PROXY / HTTPS_PROXY in its environment and the Windows system proxy. respect_system_proxy = true fixes the main app's HTTP and Responses WebSocket, but does not reach this host.

    So on this version the only working configuration is a transparent proxy (TUN). Everything else (env vars, launch.mjs / cua-repl.mjs patches, [mcp_servers.cua_repl.env] overrides) cannot influence the authenticated_fetch host.

    Request: could node_repl.exe's authenticated-fetch path honor respect_system_proxy (or HTTP_PROXY / HTTPS_PROXY), the same way the main app already does? That would resolve this whole family of issues (#44135, #44364, #44383, #44697, #44801, #45249, #45340, #45576, and the macOS variant #21713 / #23504) for users behind a local proxy without requiring TUN.

  18. mrg1130 commented on Sep 15, 2026

    @mrg1130
    mrg1130
    on Sep 15, 2026 – with ChatGPT Codex Connector

    Additional reproduction on 2026-09-16: the same Windows browser-control failure persists after the user reinstalled the browser plugin.

    Environment:

    • Codex Windows app package: 26.908.9136.0
    • Bundled Chrome/browser-control plugin: 26.908.70816
    • Chrome extension: 1.26.901.11451_0, installed and enabled in the Default profile

    Reproduction:

    1. Open Chrome with a normal website already loaded.
    2. Call await cua.getState(); through mcp__cua_repl.js.
    3. After approximately 21 seconds, receive:
    {"apps":[],"browsers":[],"errors":["Browsers: Error: nodeRepl.fetch request failed"]}
    1. Reset the control session using js_reset and retry: identical failure.

    Completed diagnostics and recovery attempts:

    • User restarted Codex and manually opened the target website.
    • User subsequently reinstalled the browser plugin; failure still reproduced.
    • Official check-extension-installed.js --browser chrome --json passes: installed=true, enabled=true, registered=true, no disable reasons.
    • Official check-native-host-manifest.js --browser chrome --json passes: correct=true, registryMatchesManifestPath=true, missingExpectedOrigins=[].
    • Native host executable exists and its process was running during diagnosis.
    • Official open-chrome-window.js --browser chrome --json successfully opened a window in the selected profile, but browser discovery still failed.
    • Desktop logs showed the browser-use native pipe listening.

    An earlier native computer-use observation of Chrome separately stopped with: "could not determine the current browser URL on Windows with enough confidence to enforce policy." The current CUA discovery attempts return the fetch error above, without that safety-stop message. These are observed symptoms; a shared root cause has not been established.

    Expected: enumerate browser tabs and permit authorized browser interaction. Actual: no browser inventory is returned, blocking browser-based work entirely. Please investigate the Windows desktop/control-runtime communication path and provide a supported recovery procedure.

    This report includes selected diagnostic facts only; no credentials, cookies, account identifiers, private browsing URLs, local user paths, or raw session logs are attached.

  19. 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，应以实际启动链路为准。

  20. Hxx-Gi commented on Sep 20, 2026

    @Hxx-Gi
    Hxx-Gi
    on Sep 20, 2026

    I am experiencing the same issue on Windows.

    Codex detects two Chrome connections, but attempting to list tabs consistently fails with:

    nodeRepl.fetch request failed

    Additional diagnostics:

    • Windows
    • Chrome is detected successfully
    • Codex can establish outbound TCP connections to chatgpt.com:443
    • Clash logs confirm codex.exe -> chatgpt.com:443
    • The connection matches the ChatGPT proxy rule and is routed through the proxy
    • Normal ChatGPT WebSocket connectivity works (wss://ws.chatgpt.com returns 101 Switching Protocols)
    • Reinstalling/restarting Chrome/Codex does not resolve the issue
    • The failure occurs specifically when Codex attempts to retrieve the Chrome tab list

    I also submitted diagnostics from the Codex app.

    Feedback ID:
    01a0bc79-a514-7411-9e62-81c6b429375a

    The Codex UI reports:
    Detected two Chrome connections, but fetching tabs from both returns nodeRepl.fetch request failed.

    Could you confirm whether this is the same underlying Windows browser-control issue, and whether the launch.js / proxy environment workaround discussed here is currently the recommended workaround?

  21. Hxx-Gi commented on Sep 20, 2026

    @Hxx-Gi
    Hxx-Gi
    on Sep 20, 2026

    I am experiencing the same issue on Windows.

    Codex detects two Chrome connections, but attempting to list tabs consistently fails with:

    nodeRepl.fetch request failed

    Additional diagnostics:

    • Windows
    • Chrome is detected successfully
    • Codex can establish outbound TCP connections to chatgpt.com:443
    • Clash logs confirm codex.exe -> chatgpt.com:443
    • The connection matches the ChatGPT proxy rule and is routed through the proxy
    • Normal ChatGPT WebSocket connectivity works (wss://ws.chatgpt.com returns 101 Switching Protocols)
    • Reinstalling/restarting Chrome/Codex does not resolve the issue
    • The failure occurs specifically when Codex attempts to retrieve the Chrome tab list

    I also submitted diagnostics from the Codex app.

    Feedback ID:
    01a0bc79-a514-7411-9e62-81c6b429375a

    The Codex UI reports:
    Detected two Chrome connections, but fetching tabs from both returns nodeRepl.fetch request failed.

    Could you confirm whether this is the same underlying Windows browser-control issue, and whether the launch.js / proxy environment workaround discussed here is currently the recommended workaround?

  22. Hxx-Gi commented on Sep 20, 2026

    @Hxx-Gi
    Hxx-Gi
    on Sep 20, 2026

    I am experiencing the same issue on Windows.

    Codex detects two Chrome connections, but attempting to list tabs consistently fails with:

    nodeRepl.fetch request failed

    Additional diagnostics:

    • Windows
    • Chrome is detected successfully
    • Codex can establish outbound TCP connections to chatgpt.com:443
    • Clash logs confirm codex.exe -> chatgpt.com:443
    • The connection matches the ChatGPT proxy rule and is routed through the proxy
    • Normal ChatGPT WebSocket connectivity works (wss://ws.chatgpt.com returns 101 Switching Protocols)
    • Reinstalling/restarting Chrome/Codex does not resolve the issue
    • The failure occurs specifically when Codex attempts to retrieve the Chrome tab list

    I also submitted diagnostics from the Codex app.

    Feedback ID:
    01a0bc79-a514-7411-9e62-81c6b429375a

    The Codex UI reports:
    Detected two Chrome connections, but fetching tabs from both returns nodeRepl.fetch request failed.

    Could you confirm whether this is the same underlying Windows browser-control issue, and whether the launch.js / proxy environment workaround discussed here is currently the recommended workaround?

  23. VidyFoo commented on Sep 27, 2026

    @VidyFoo
    VidyFoo
    on Sep 27, 2026 – with ChatGPT Codex Connector

    This adds measured macOS evidence for the TUN suggestion in this thread. We did not verify a Windows fix or equate main-app proxy connectivity with helper-process connectivity.

    On September 27, 2026, enabling FlClash TUN restored actual Chrome control on desktop 26.924.22138 (build 11645) with extension 1.26.901.11451_0.

    Before: system proxy enabled, extension/native-host checks passed, side panel worked, but browser tools timed out. The app-bundled Node helper was observed making stalled direct connections. After the user enabled TUN: the supported CUA tool returned all 11 Chrome tabs, opened https://example.com/, read its heading/body/link, and closed the test tab successfully. No official runtime/plugin files or authentication/security checks were patched.

    Full diagnostic evidence and verification.

    This is an environment-specific workaround where direct connectivity is unavailable and helper traffic needs the existing proxy. It requires TUN to remain operational, does not identify the exact failed authenticated prerequisite, and is not a universal fix for every nodeRepl.fetch error. No private logs or browser contents are attached.

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 workingwindows-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