Repository navigation
[Windows 11][26.903.9818.0] Chrome and Edge discovered, but tab operations fail after ~21s; cua_repl proxy override removed on restart #44801
Description
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.mjsentry 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:
- Browser inventory succeeded without the former fetch error (approximately 2.5 seconds).
- Edge opened
https://example.com/, returned readable page content, clicked the page's link, and returned the IANA Example Domains destination content. - After opening Chrome, the tool successfully listed existing Chrome tab titles and URLs.
- Chrome opened
https://example.com/and read its content (approximately 0.86 seconds). - Chrome clicked the link and read
https://www.iana.org/help/example-domains(approximately 2.13 seconds). - 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
- Start the desktop app and Chrome with the official extension enabled.
- Discover available browser providers using the installed CUA API. Chrome is returned successfully.
- Run
cua.listTabs({browser: "<returned Chrome browser id>"}). - Wait approximately 21 seconds; the call fails with the message above.
- Open Edge with its connected extension and repeat using the returned Edge browser ID.
- 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
github-actions commentedon Sep 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
jiangzhizhuo301-Cyril commentedon Sep 13, 2026
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.
VidyFoo commentedon Sep 27, 2026
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.fetcherror. No private logs or browser contents are attached.