Skip to content

[Windows][Desktop] Chrome discovered but list/open tabs fail with nodeRepl.fetch on 26.915.4065.0 #47732

Open
Open
[Windows][Desktop] Chrome discovered but list/open tabs fail with nodeRepl.fetch on 26.915.4065.0#47732
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

@kris-0123
kris-0123
opened on Sep 24, 2026

Summary

The Chrome plugin in Codex Desktop on Windows is unusable in this environment. Chrome can be discovered as an extension-backed browser, but listing tabs or opening a requested page fails with nodeRepl.fetch request failed.

This is an additional environment report on a newer desktop package than #45249. Please link or consolidate it with the existing tracking issue if appropriate. The root cause has not been established.

Environment

  • OS: Windows 10 Pro, version 10.0.19045, build 19045, x64.
  • Codex desktop MSIX package: OpenAI.Codex_26.915.4065.0_x64 (verified from the running application path).
  • Bundled Chrome / Computer Use component manifests: 26.915.31945.
  • Google Chrome installed binary version: 153.0.8010.53.
  • Chrome connection extension version: 1.26.901.11451_0.
  • Extension ID: hehggadaopoacecdllhhajmbjkdcmajg.
  • Local HTTP proxy software is present. The environment's NO_PROXY contains localhost,127.0.0.1,::1. No controlled proxy A/B test was completed in this report.
  • Observed repeatedly during troubleshooting on September 23–24, 2026.

Steps to reproduce

  1. Open Chrome using a profile with the OpenAI connection extension installed and enabled.
  2. Open a local Codex desktop task and invoke @Chrome with an ordinary navigation/search request.
  3. The browser-control runtime can successfully execute await cua.listBrowsers() and return a Chrome backend with family: "chrome" and type: "extension".
  4. Use the exact returned browser ID to request its tabs, for example await cua.listTabs({browser: "2"}) when the discovered ID is 2.
  5. The call fails with nodeRepl.fetch request failed. Earlier repetitions took approximately 21 seconds; the most recent repetition took approximately 14.6 seconds.
  6. Opening a new Chrome tab through cua.createBrowserTab("chrome", ...) also failed. Its completion could not be verified because the subsequent tab-list call failed as well.

Expected behavior

Codex should list the tabs in the discovered Chrome profile, open the requested page, and return readable page state.

Actual behavior

cua.listBrowsers(): Chrome extension backend discovered
cua.listTabs({browser: "<returned-id>"}): nodeRepl.fetch request failed
cua.createBrowserTab("chrome", ...): nodeRepl.fetch request failed

At other points the Chrome backend disappeared between discovery and selection, producing Browser is not available.

The latest failed attempt also emitted networking errors for requests to ab.chatgpt.com from the Statsig client. Those errors occurred alongside the browser-control failure; causation has not been established. Full request URLs and query parameters are intentionally omitted.

Checks already completed

  • The desktop settings UI reports Google Chrome as installed, with browsing allowed.
  • Both chrome@openai-bundled and computer-use@openai-bundled have enabled = true in the local configuration.
  • There was a difference between Chrome profiles: the default profile did not have the extension during the latest inventory, while another profile had it installed and enabled. Opening the enabled profile restored browser discovery, but tab listing still failed. This does not fully explain the problem.
  • The bundled native-host-manifest diagnostic returned correct: true, with matching registry/manifest paths and the expected allowed extension origins.
  • The native messaging host executable exists, and extension-host.exe was observed running during reproduction.
  • Resetting the browser tool's JavaScript session did not restore control.
  • Bringing the current Codex task to the foreground and reopening its browser panel temporarily restored some discovery responses, but Chrome tab operations continued to fail.
  • Restarting the desktop app/browser and checking the extension were already tried by the user without resolution.

Additional diagnostic clue

Desktop logs repeatedly include:

No ChatGPT browser route is available for browser session <redacted-current-task-id>

Some consecutive in-app-browser getInfo requests failed and then succeeded; similar failures later recurred. This may be relevant to task/session routing, but it has not been proven to cause the Chrome failure.

Impact and requested help

The issue has blocked ordinary browser work for the user over an extended period. Please investigate the Windows browser-control request path after successful backend discovery, and provide either a verified fix/workaround or a supported way to obtain the underlying transport error code.

Related reports

Only the checks above were performed in this environment. Troubleshooting steps from the linked reports are not being claimed as performed here.

Privacy

This report includes only selected diagnostic facts. It does not attach screenshots, raw logs, conversation contents, account identifiers, profile names, private local paths, tokens, cookies, or browser storage.

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 24, 2026

  2. github-actions commented on Sep 24, 2026

    @github-actions
    github-actionsbot
    on Sep 24, 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. mrli343 commented on Sep 26, 2026

    @mrli343
    mrli343
    on Sep 26, 2026

    Additional reproduction on Codex 26.924.22138, observed September 26, 2026, with a separate network diagnostic that may help narrow this down.

    Environment

    • Windows build 10.0.26200.0.
    • Codex product version 26.924.22138, build 11645, channel prod; the app's update check reported up_to_date for that channel.
    • MSIX package version 26.924.2738.0 (a different version field from the product version).
    • Chrome 153.0.8010.54; connection extension 1.26.901.11451.
    • An existing Windows system proxy is enabled; no PAC configuration.

    Reproduction and observed results

    1. Manually open Chrome and its ChatGPT extension side panel.
    2. cua.listBrowsers() successfully discovers Chrome with family: "chrome", type: "extension" and browser ID 2 in this run.
    3. cua.createBrowserTab("chrome", "about:blank", {sessionName: "🔎 Chrome 连接诊断"}) fails with nodeRepl.fetch request failed (about 14.7 seconds).
    4. A subsequent read-only cua.listTabs({browser: "2", emit: false}) fails with the same error (about 2.3 seconds).

    No usable tab handle was returned. Whether the failed create operation left a blank tab could not be verified because listing also failed. Expected behavior is successful tab creation/listing for the discovered Chrome backend. The failure blocks browser work before any target website is accessed.

    The bundled extension diagnostic reports installed/enabled/registered, with no disable reasons. Native-host registration, the host executable, and the expected extension origin are present; the native host was also observed running. These checks establish installation state, not working browser control.

    New diagnostic clue: separate, unauthenticated network probe

    Using the packaged Node binary (v24.21.0) in separate processes, a HEAD request to the public https://chatgpt.com/robots.txt endpoint produced:

    Mode Result Elapsed
    Direct connection TypeError, cause code ECONNREFUSED 2,804 ms
    Existing system proxy supplied to the test process HTTP 200 3,957 ms

    The probe used no login credentials and read no response body. Proxy variables were temporary to the test process. The managed browser-tool manifest did not explicitly configure proxy variables, but the actual running browser-tool process environment was not inspected.

    This is a diagnostic clue, not proof of the root cause: the probe did not exercise the actual CUA request destination, authenticated transport, or browser-control path. No browser-tool configuration patch or application restart has been applied, and Chrome control remains unresolved.

    Is there a supported way to inspect the underlying transport error or configure proxy inheritance for the Windows browser-control process? A clearer error than nodeRepl.fetch request failed would help distinguish network reachability from session routing or authentication failures.

  4. VidyFoo commented on Sep 27, 2026

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

    Verified workaround on macOS for the same discovery-success / browser-control-timeout symptom, tested September 27, 2026: enabling FlClash TUN restored actual Chrome tab enumeration and page reading.

    This is a separate macOS reproduction, not confirmation of a Windows fix. It also relates to #46609 and #43787.

    Environment:

    • ChatGPT/Codex desktop 26.924.22138, build 11645.
    • Google Chrome 154.0.8037.57.
    • ChatGPT Chrome extension 1.26.901.11451_0.
    • Bundled Node v24.21.0.

    Before enabling TUN:

    • macOS system HTTP/HTTPS proxy was enabled and the existing local FlClash proxy listener was running.
    • A separate initial macOS permission problem had already been corrected: ChatGPT's Files & Folders permission for Google Chrome was enabled. The official extension and native-host-manifest diagnostics then both passed, and the extension side panel displayed its normal chat UI.
    • Despite that, Chrome discovery could succeed while tab/session operations timed out at roughly 30 seconds; subsequent discovery also returned nodeRepl.fetch request failed.
    • Read-only socket inspection showed an app-bundled node_repl process making direct TCP connections, stuck in SYN_SENT, to addresses matching the local DNS results for chatgpt.com and ab.chatgpt.com.
    • Separate unauthenticated probes to the identity and initialization endpoints timed out when direct, but received HTTP 403 in about 0.4 seconds through the existing proxy. These probes establish a reachability difference only, not successful authentication.

    Workaround and verification:

    1. The user enabled TUN mode in the already-installed FlClash client.
    2. Retested the supported CUA browser tools in the same chat.
    3. cua.getState() successfully returned Chrome and its 11 open tabs (tool call about 7.8 seconds).
    4. cua.createBrowserTab(..., "https://example.com", ...) succeeded (tool call about 1 second), returning the Example Domain heading, body text and link.
    5. Closed the temporary test tab successfully.

    No official application/plugin files, native-host binaries, certificate checks, or authentication policy were patched to obtain this result.

    Interpretation: this before/after result strongly supports network routing as a blocker in this environment. TUN can cover traffic from helper processes that do not use the system HTTP proxy. It does not establish which internal authenticated request originally failed, a universal root cause for this issue, or that every similar failure is fixed by TUN. TUN must remain operational for this workaround where direct connectivity is unavailable; it is not a fix for operation with the proxy fully stopped.

    A supported way for browser helper processes to honor OS proxy settings, plus errors identifying the failed network prerequisite, would help avoid repeated extension reinstalls.

    No private URLs, account identifiers, credentials, browser contents, or raw logs are attached.

  5. zbzbdzb commented on Sep 29, 2026

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

    Additional Windows reproduction and transport-boundary evidence on Codex Desktop 26.924.22138, build 11645, prod; Store package 26.924.2738.0; bundled Node 24.21.0.

    With the original CUA launcher restored, no custom Codex HTTP(S) proxy environment configuration, and a full Desktop restart:

    • Official CUA can create and read an IAB tab for a loopback application in approximately 2 seconds.
    • Creating a Chrome tab for the same application fails in approximately 21.5 seconds with nodeRepl.fetch request failed.
    • Read-only inspection of the new CUA process environments finds HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, NO_PROXY and NODE_USE_ENV_PROXY unset. Windows has an enabled, working local system proxy; TUN is off.
    • During a Chrome call, TCP metadata sampling observes the CUA Rust host attempting direct public HTTPS connections and no connection from that host to the local proxy. The main app-server is connected to the proxy at the same time. This is correlation, not a mapping of individual authenticated requests to sockets.

    Subsequent controlled network change: after the user enabled the existing proxy client's TUN adapter, with the same original runtime/configuration and a fresh CUA state, Chrome control succeeded. We verified creation and reading of the loopback page, local navigation by clicking, external HTTPS navigation, following a visible link and reading the destination, and closing the test tab. No runtime patch, feature toggle or policy bypass was used. The immediately preceding system-proxy/global-mode test with TUN off still failed after approximately 21.7 seconds. This establishes a working TUN-on path, not dynamic system-proxy support when TUN is off.

    Further A/B observation: after the user switched to another working proxy node with TUN still enabled, resetting the JavaScript state and initializing Chrome succeeded again, with verified local clicks and external page reads. After disabling TUN while retaining the system proxy, the existing initialized JS session could still follow a link and read the destination. However, after cleaning up its test tab and resetting the JS kernel, initialization failed again after approximately 21.8 seconds. Thus a previously initialized session continuing to work with TUN off is insufficient evidence of a fix. js_reset resets JavaScript bindings; it is not a verified restart of the Rust host or its connection pool. Full-process restart, local-port changes and runtime updates are not claimed as tested.

    The actual fetch path appears independent of Node global fetch. The installed node_repl.exe embeds the privileged JS message type: "authenticated_fetch", src/authenticated_fetch.rs, the exact observed error string, and reqwest 0.12.28 / hyper-util 0.1.20. An independent Node globalThis.fetch test with NODE_USE_ENV_PROXY therefore does not establish the behavior of this Rust path.

    The installed host contains proxy environment variable names, but an ASCII/UTF-16 presence check did not find respect_system_proxy, system_proxy_fallback, or the Windows registry constants Internet Settings, ProxyEnable, and ProxyServer. Upstream reqwest/hyper-util gates Windows system-proxy discovery behind a separate compile feature. This suggests a missing system-proxy capability in the independent host, but string absence is not conclusive build-feature proof.

    A user configuration overlay does not currently appear to solve this durably. A read-only CLI probe that supplies the same official executable plus one harmless environment marker parses successfully, but replaces the entire CUA registration: the original script argument, 18 generated environment entries and other launch/tool settings are absent. This does not prove a complete copied registration could not run; it means it would have to copy Desktop-generated runtime, service, pipe and tool metadata. The public plugin configuration schema intentionally excludes transport fields, and the public MCP catalog chooses a whole registration rather than deep-merging it. No services were started with the probe, and no persistent configuration was written.

    Could maintainers clarify:

    1. Does the installed NodeREPL authenticated-fetch host include Windows system-proxy support? Does it use the app-server respect_system_proxy feature, or a separate client?
    2. Is there a supported configuration that dynamically follows the current Windows proxy without copying Desktop-generated launch metadata or patching bundled files?
    3. Is there a fixed Desktop build, or a supported recovery procedure that preserves the existing browser permissions and security policy?
    4. Can diagnostics expose the failing destination/status/transport error without logging credentials, cookies or response bodies?

    The required behavior is: proxy stays enabled; switching proxy nodes or local ports and enabling/disabling TUN should recover automatically; replacing the Codex runtime should not require reapplying a patch. Proxy-off operation is not required. A TUN-always-on workaround does not cover the full requirement.

    No TLS, authentication, URL-policy or request-header-policy checks were disabled. This report omits private URLs, usernames, local paths, port values, process/session identifiers, credentials, cookies, tokens and raw logs.

  6. q3579338 commented on Oct 8, 2026

    @q3579338
    q3579338
    on Oct 8, 2026

    Windows workaround without TUN: inject proxy env into the CUA/node_repl launch configs

    Reproduction confirmed on Windows 10 Pro (build 19045), Codex Desktop 26.1002.52244 (product) / 26.1002.7124.0 (MSIX), bundled Node 24.21.0, Chrome extension 1.26.901.x. Same symptom: cua.listBrowsers() discovers Chrome (family chrome, type extension), but listTabs/createBrowserTab fail with nodeRepl.fetch request failed (~14-21s) whenever TUN is off and only a system HTTP proxy is present.

    What worked without TUN: after injecting proxy env vars into the CUA/node_repl launch configuration (not just the user/system environment), Chrome tab enumeration and page reads succeeded with the system proxy (TUN off). Three injection points, all re-appliable after every auto-update:

    1. ~/.codex/config.toml → [mcp_servers.node_repl.env] add: 
      HTTP_PROXY = "http://127.0.0.1:10809"
HTTPS_PROXY = "http://127.0.0.1:10809"
ALL_PROXY = "http://127.0.0.1:10809"
NO_PROXY = "localhost,127.0.0.1,::1,.localhost"
    2. plugins/cache/openai-bundled/unified-computer-use/<ver>/.mcp.json → mcpServers.cua_repl.env add the same HTTP_PROXY/HTTPS_PROXY/ALL_PROXY/NO_PROXY.
    3. runtimes/cua_node/<hash>/bin/node_modules/@oai/cua-repl/bin/cua-repl.mjs → set process.env.HTTP_PROXY/HTTPS_PROXY/ALL_PROXY before await import("@oai/cua-repl").

    A full Desktop restart after the edit was required (env is only read by newly-launched helper processes).

    Why the user-level env vars alone did NOT work: the Desktop MCP config uses an environment allowlist (NODE_REPL_UNTRUSTED_ENV_ALLOWLIST), so host-level HTTP_PROXY/NODE_USE_ENV_PROXY are filtered out before reaching the helper. They must be written into the MCP server env blocks above.

    Note on the fetch path: this corroborates @zbzbdzb's Rust-path finding. On this machine NODE_USE_ENV_PROXY=1 made no observable difference by itself (consistent with the fetch being the embedded Rust authenticated_fetch / reqwest path, not Node global fetch). The part that actually mattered here was the HTTP_PROXY/HTTPS_PROXY/ALL_PROXY values reaching the helper process via the config, which reqwest-based clients honor. So treat step 1+2 (the config env blocks) as the essential fix and step 3 as belt-and-suspenders.

    Caveats (same ones @zbzbdzb raised): this is a config patch, not a durable fix. It must be re-applied after every Desktop auto-update (the runtime/plugin directories get re-extracted with a new hash), and it does not solve dynamic proxy-node/port switching. A supported first-class mechanism (helper honors the Windows system proxy, or a stable per-app proxy setting that survives updates) is still the correct long-term answer.

    No private URLs, credentials, or tokens 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 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