Skip to content

[Windows 11][26.903.9818.0] Chrome and Edge discovered, but tab operations fail after ~21s; cua_repl proxy override removed on restart #44801

Open

Description

@plex2233-maker

Update — September 12, 2026: local workaround verified after restart

On the same machine, the installed desktop package is now 26.908.4834.0, with bundled browser/CUA plugin 26.908.40834. The update alone did not resolve the failure: before applying the workaround, the official CUA tool still returned nodeRepl.fetch request failed after approximately 22 seconds.

We applied the launcher-environment workaround described in #44364 (comment):

  • Followed the active plugin manifest to the current @oai/cua-repl/bin/cua-repl.mjs entry point.
  • Backed up that file and added only the seven proxy environment settings before cua_repl.launch(), pointing to the already-running local HTTP proxy.
  • Preserved all original launcher code, trusted services, enabled surfaces, identity/certificate checks, and login state.
  • Syntax and isolated child-environment checks passed.
  • Fully exited and reopened the desktop app. The patched file's hash remained unchanged after restart.

Actual verification through the official browser tool after the restart:

  1. Browser inventory succeeded without the former fetch error (approximately 2.5 seconds).
  2. Edge opened https://example.com/, returned readable page content, clicked the page's link, and returned the IANA Example Domains destination content.
  3. After opening Chrome, the tool successfully listed existing Chrome tab titles and URLs.
  4. Chrome opened https://example.com/ and read its content (approximately 0.86 seconds).
  5. Chrome clicked the link and read https://www.iana.org/help/example-domains (approximately 2.13 seconds).
  6. Chrome closed the test tab and successfully listed the remaining original user tab.

An Edge cleanup call ended with native pipe closed before response, and Edge was subsequently absent from browser discovery. We do not count that cleanup call as a verified success; the Edge opening, reading, and clicking operations above succeeded. Chrome cleanup was separately confirmed.

This establishes a working local recovery on this machine, beyond browser discovery or an unauthenticated connectivity probe. It does not establish the precise upstream environment-filtering defect or a permanent product fix. Updates may overwrite the entry point or select another runtime directory. A supported, persistent user proxy configuration is still needed, so this issue remains open.

No raw logs, private tab contents, account identifiers, or credentials are included.


Original report — September 11, 2026

Summary

On Windows 11, the desktop app discovers both Chrome and Edge extension providers, but actual browser tab operations consistently fail after approximately 21 seconds with:

nodeRepl.fetch request failed

This report adds a Windows 11 reproduction affecting both browsers and an observed loss of a manually supplied proxy configuration after a real app restart.

Related reports: #44697 (same desktop package version and timeout), #44135 (Windows browser control), #44364 (Windows proxy-related reproduction), and #42454 (generated cua_repl environment overrides). Please consolidate with an existing issue if appropriate.

Environment

  • OS: Windows 11 Pro, version 10.0.26200, build 26200, x64.
  • Installed Microsoft Store package: OpenAI.Codex, version 26.903.9818.0.
  • Bundled computer/browser-use plugin: 26.903.71938.
  • Google Chrome: 152.0.7977.84.
  • Microsoft Edge: also reproduces; exact version was not collected.
  • Official Chrome extension ID: hehggadaopoacecdllhhajmbjkdcmajg.
  • Windows system proxy is enabled and points to a running local HTTP proxy. HTTP_PROXY / HTTPS_PROXY are absent from the effective managed cua_repl configuration.
  • Tested on September 11, 2026.

Steps to reproduce

  1. Start the desktop app and Chrome with the official extension enabled.
  2. Discover available browser providers using the installed CUA API. Chrome is returned successfully.
  3. Run cua.listTabs({browser: "<returned Chrome browser id>"}).
  4. Wait approximately 21 seconds; the call fails with the message above.
  5. Open Edge with its connected extension and repeat using the returned Edge browser ID.
  6. Observe the same failure.

Observed measurements:

Operation Result
Browser discovery after app restart Succeeds; approximately 0.1 seconds
Chrome listTabs after app restart and reopening Chrome Fails after 21.0706 seconds
Edge listTabs Fails after 21.0872 seconds
createBrowserTab("chrome", "about:blank", {sessionName: "Connection check"}) in separate attempts Fails after approximately 21.3 seconds

No actual page title or URL was returned by the failed tab operations.

Checks and recovery attempts

  • Reinstalled the Chrome extension and restarted the desktop app/browser.
  • Reset the CUA JavaScript session and retried.
  • Official native-host manifest validation passes, including host name, registry registration, executable path, and allowed extension origin.
  • The native-host executable exists, and Chrome launching the extension-host process was observed.
  • Both browser providers are discoverable; extension discovery alone does not establish successful tab control.

Proxy configuration persistence observation

We temporarily added the complete current official cua_repl MCP definition to the personal config, preserving its command, arguments, tool restrictions, trusted-service configuration, and existing environment. Only HTTP_PROXY, HTTPS_PROXY and a localhost NO_PROXY exclusion were added, pointing to the already-running local proxy.

The bundled CLI parsed this definition and resolved the added environment variables. After fully exiting and reopening the desktop app:

  • The personal config was rewritten.
  • The manual cua_repl block was absent.
  • The effective cua_repl proxy variables were absent again.
  • The local proxy was still running.
  • The Chrome tab operation still failed.

Therefore this was not a successful test of the candidate proxy fix in a restarted runtime, and it is not a validated workaround.

Unauthenticated HEAD requests to the public chatgpt.com and ab.chatgpt.com roots timed out when direct, while the existing local proxy returned HTTP 403 in roughly 1.5 seconds. This demonstrates a transport difference, not successful authenticated API access.

Expected behavior and uncertainty

After discovering a connected browser, the app should return tabs or an actionable underlying error. Please provide a supported, persistent proxy configuration path for the generated CUA runtime.

An update regression and missing proxy propagation are plausible hypotheses, but the exact failing endpoint and the last working desktop version on this machine have not been established. We have not tested the workaround described in #44364 on this machine.

No identity checks, browser policy checks, TLS validation, or login state were changed. This report intentionally excludes account identifiers, private task content, local usernames, credentials, and raw logs.

Activity

  1. added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    windows-osIssues related to Codex on Windows systems
    connectivityIssues involving networking or endpoint connectivity problems (disconnections)
    configIssues involving config.toml, config keys, config merging, or config updates
    on Sep 11, 2026
  2. jiangzhizhuo301-Cyril commented on Sep 13, 2026

    @jiangzhizhuo301-Cyril

    Adding a confirmed data point on plugin 26.908.40834 (Windows).
    On this machine the plugin cache directory …\unified-computer-use\26.908.40834
    initially contained only .mcp.json and the plugin manifest — no scripts\launch.mjs,
    and no cua-repl.mjs anywhere on disk — so the #44364 launcher workaround could
    not be applied as-is. The injection point on this build is
    @oai/cua-repl/bin/cua-repl.mjs: adding the seven proxy env vars
    (NODE_USE_ENV_PROXY=1, HTTP_PROXY/HTTPS_PROXY, NO_PROXY incl. localhost/127.0.0.1/::1)
    before cua_repl.launch() restored browser control completely: tab attach went
    from "nodeRepl.fetch request failed" (~21 s timeout) to ~3.4 s, including reading
    an already-logged-in Web of Science tab in Edge.
    Root cause here: the browser-control Node child does not use the Windows system
    proxy, and direct connections to the required endpoints are blocked by the local
    network.
    Note for others: after restarts the plugin directory layout changed and
    cua-repl.mjs only appeared later — follow the active plugin manifest to find the
    current entry point. A stable env override (per #42454) would save a lot of pain.

  3. VidyFoo commented on Sep 27, 2026

    @VidyFoo

    This provides an alternative network-routing workaround that did not require patching a bundled launcher. Our verification was on macOS, not the Windows environment here.

    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 workingconfigIssues involving config.toml, config keys, config merging, or config updatesconnectivityIssues 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