Repository navigation
[Windows][Desktop] Chrome discovery succeeds but listTabs fails after ~21s, even after Doctor WebSocket recovery #45249
Description
Summary
On Windows, Codex discovers the running Chrome extension backend, but cua.listTabs({browser:"chrome"}) consistently fails after approximately 21 seconds with nodeRepl.fetch request failed. Chrome discovery, extension registration, and Native Messaging validation succeed. Restoring Codex Doctor's Responses WebSocket connectivity does not resolve the tab-listing failure.
Environment
- Windows 11 Pro 10.0.22621
- Codex Desktop 26.908.4834.0
- Codex CLI 0.154.0-alpha.6.2
- Google Chrome: running normally; exact Chrome version not recorded in this report
- Chrome profile: Profile 1 / profileName
jun - Chrome extension ID:
hehggadaopoacecdllhhajmbjkdcmajg - Subscription: not specified
Steps to reproduce
- Run Google Chrome with the above profile and its installed, registered, enabled extension.
- In Codex's browser-control runtime, call:
Chrome is returned with
await cua.listBrowsers()
id=2, family=chrome, type=extension, profileName=jun. - Call:
await cua.listTabs({browser:"chrome"})
- After approximately 21 seconds, observe
nodeRepl.fetch request failed. This was consistently reproducible during the diagnostic session. - Explicitly set
HTTP_PROXY,HTTPS_PROXY, andALL_PROXYtohttp://127.0.0.1:10808in the diagnostic environment and rerun Codex Doctor. The previous Responses WebSocket handshake timeout becomes a successful HTTP 101 connection, but the tab-listing call still fails.
Expected behavior
Codex should enumerate tabs from the discovered Chrome profile so browser-control work can proceed.
Actual behavior and key diagnostic output
The following are selected results from the completed diagnostic session, not a fresh reproduction or an unabridged log:
installed-browsers: Chrome correctly detected
Chrome extension:
installed=true
registered=true
enabled=true
Native Host validation:
correct=true
registryMatchesManifestPath=true
missingExpectedOrigins=[]
open-chrome-window.js --browser chrome: succeeds
cua.listBrowsers(): succeeds
id=2
family=chrome
type=extension
profileName=jun
cua.listTabs({browser:"chrome"}): fails after ~21 seconds
nodeRepl.fetch request failed
Error: nodeRepl.fetch request failed
at kernel.js:1595:16
[remaining stack omitted]
Codex Doctor before explicit proxy settings:
Responses WebSocket handshake timeout
Codex Doctor after explicit proxy settings:
websocket connected (HTTP 101 Switching Protocols)
Chrome listTabs after WebSocket recovery:
nodeRepl.fetch request failed
Troubleshooting already completed
- Confirmed Chrome runs normally and installed-browsers discovers it.
- Verified the selected Chrome profile and extension installation, registration, and enabled state.
- Validated the Native Host manifest, matching registry path, and expected allowed origins.
- Successfully launched Chrome using the supplied open-chrome-window helper.
- Confirmed browser discovery succeeds independently of tab enumeration.
- Resolved the Doctor WebSocket handshake failure using explicit proxy variables; verified that this does not resolve listTabs.
These checks provide no evidence of a Chrome configuration error. Please investigate the Windows browser-control/tab RPC path; the exact root cause is not yet established. A successful Responses WebSocket handshake alone does not demonstrate that the browser-control transport is healthy.
Related symptom report: #44697. This report adds the environment above and the successful-Doctor/failed-listTabs diagnostic distinction.
Privacy
Only selected diagnostic facts are included. No authentication tokens, cookies, account identifiers, full private local paths, browsing URLs, or raw session/log attachments are provided.
Activity
github-actions commentedon Sep 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
chaichai52229364-ctrl commentedon Sep 13, 2026
The same diagnostic report was also submitted to Codex feedback through the local app-server
feedback/uploadAPI.Feedback receipt ID:
no-active-thread-01a09b77-4bfa-7f12-a960-6b18f9c7d4d2The submission contains the selected diagnostic text and a link to this issue. Raw logs and conversation attachments were excluded (
includeLogs=false) to avoid sharing sensitive information.KaelCJ commentedon Sep 14, 2026
I reproduced a closely matching variant in another Windows environment.
Environment
10.0.19045, x64)26.903.8094.00.153.426.903.61454152.0.7977.83150.0.4078.48Additional reproduction evidence
A fresh
setupBrowserRuntime({ environment: "codex-app" })successfully enumerates Chrome, Edge, and Codex In-app Browser.The official
scripts/open-chrome-window.js --browser chromerecovery command succeeds and opens a new window in the selected profile.After waiting two seconds and initializing another fresh browser runtime, Chrome and Edge receive newly registered browser/extension instances. This confirms that discovery and extension-instance registration are occurring rather than an old browser object merely being reused.
tabs.list()against the newly registered Chrome instance still fails after approximately 21 seconds with:tabs.list()against the newly registered Edge instance fails the same way.As a control,
tabs.list()against the freshly registered Codex In-app Browser succeeds immediately and returns an empty tab list.Checks that pass
session_idandturn_id.Recycling an isolated stale CUA helper process tree did not resolve the failure. No main Codex process, shared app-server process, native-host manifest, registry configuration, browser cookies, or site data was modified.
This appears to narrow the failure to the external Chrome/Edge extension or Native Messaging RPC path. The IAB backend remains healthy in the same fresh runtime, and the issue is not explained by stale browser IDs, missing turn metadata, extension installation state, or static Native Messaging configuration.
Could maintainers investigate the external-browser tab RPC path and expose the underlying transport/authenticated-fetch error instead of reducing it to
nodeRepl.fetch request failed? A supported recovery path beyond reopening the selected browser profile would also help.wushuosishi commentedon Sep 15, 2026
Additional reproduction on Windows, 2026-09-15.
I am seeing the same failure pattern:
Current user-facing error from Codex:
A prior attempt in the same setup reported that the browser tab could be recognized, but the computer/page-reading channel was unavailable and the corresponding connection pipe could not be found.
This appears consistent with the report here: browser discovery/registration can succeed while the tab/page-control RPC path is unavailable.
No account identifiers, session IDs, credentials, cookies, or private page contents are included in this report.
Lesterffx commentedon Sep 15, 2026
Additional reproduction on Windows.
nodeRepl.fetch request failed.The exact failing layer has not been identified. More specific error diagnostics and a supported recovery procedure would help.
This report excludes personal paths, account details, webpage content, and raw logs.
319039688zwj-cpu commentedon Sep 30, 2026
I can reproduce the same issue on a newer Windows Codex Desktop build.
26.928.21956/ AppX26.928.2636.01.26.901.11451nodeRepl.fetch request failednode_repl.exeprocesses after restart.chatgpt.com:443both work.curlthrough my local proxy127.0.0.1:10808reaches ChatGPT and gets HTTP 403.HTTP_PROXY/HTTPS_PROXYpointing to the same proxy does not fix Chrome tab control.So the Chrome tab/listTabs RPC still fails consistently on
26.928.x. This looks like the same WindowsnodeRepl.fetchbrowser-control issarriannayfq commentedon Oct 1, 2026
Latest status: original Chrome, Edge and in-app-browser control recovered; full input/save/reload verification passed. Persistence across a full app restart or update remains unverified. See the recovery update below.
Additional reproduction on Windows on 2026-10-01, with a useful working-vs-failing control.
Environment:
Working path:
The Chrome extension side panel displays chat normally. In a side-panel chat, getTabContext for the selected tab returned the actual rendered page text in about 0.7 seconds. The tool result was inspected, rather than relying on the assistant's claim that it had read the page. The test page was the public documentation at https://learn.chatgpt.com/docs/chrome-extension.
Failing path:
In a fresh desktop diagnostic chat, cua.getState discovers both Chrome and Edge extension instances, but their tab inventories fail with nodeRepl.fetch request failed. Reading the same Chrome page with cua.getTab by URL fails after about 21.7 seconds. A separate call using the real tab ID obtained from the successful side-panel read also fails after about 21.1 seconds. No page state is returned and no click/input is attempted.
Checks that pass:
The bundled installed-browsers, chrome-is-running, check-extension-installed and check-native-host-manifest scripts all pass for the tested Chrome/Edge setup. Both extensions are installed and enabled, the shared Windows native-host registration and allowed origins are correct, the configured executable exists, and each browser has a running extension-host process. The user has already rebooted Windows, switched VPN connections, and reinstalled the Chrome extension; a fresh chat did not resolve the failure.
Separate IAB observation:
Creating the same public documentation page times out in CUA, while the desktop log records webview attachment, tab mapping and the target URL's dom-ready. Binding the created page subsequently also times out. During these requests, getInfo completion and missing-route errors coexist. We therefore do not treat missing-route alone as proof that every route is absent, or assume the IAB and external-browser failures have the same root cause.
Could maintainers investigate the difference between side-panel getTabContext and CUA tab RPC, and provide a supported diagnostic that exposes the underlying timeout/transport failure stage? Is there a supported recovery procedure or a confirmed fixed build?
Only selected technical observations are included. No private page content, profile names, local paths, account identifiers, conversation/tab IDs, credentials, cookies or raw logs are attached.
Update from subsequent network checks and a scoped correction:
The Windows user-level and inherited process HTTPS_PROXY pointed to http://127.0.0.1:7890, where no listener was present. The current Windows system proxy points to http://127.0.0.1:7897, with an active local proxy listener. Official npm metadata requests through the inherited proxy failed with ECONNREFUSED; requests explicitly through the current system proxy succeeded.
With user authorization, the original user-level value was backed up and only that HTTPS_PROXY variable was changed to http://127.0.0.1:7897. Registry readback matched. A verification child process that explicitly loaded the corrected user value successfully fetched official npm metadata with retries disabled. No package was installed.
Post-relaunch result on 2026-10-01:
The user fully exited and reopened the desktop app. Both the user-level value and a fresh ordinary tool subprocess now report HTTPS_PROXY=http://127.0.0.1:7897, and the expected loopback listener is present. No per-command proxy override was used for these CUA retries.
The correction did not restore CUA. Edge tab inventory still failed with nodeRepl.fetch request failed after about 21 seconds. Chrome had been closed; after using the bundled, supported selected-profile launch script, Chrome was rediscovered, but its tab inventory failed with the same error after about 22 seconds. The IAB public documentation tab reached dom-ready and appeared in the returned inventory with the correct title and URL. Its creation call nevertheless timed out at 45 seconds, and a subsequent binding using that returned tab identifier timed out at 30 seconds. No browser page state or interaction was obtained through these CUA calls.
This rules out the stale shell HTTPS_PROXY value as a sufficient explanation/remedy for the observed CUA failures. It does not establish the actual proxy selected inside nodeRepl.fetch or identify the lower-level failing stage.
As a separate user-authorized fallback feasibility test, Microsoft's official Playwright MCP, over local standard stdio, controlled an isolated Chrome session and a new self-owned loopback fixture. Reading, clicking, text input, a fixture-only save, reload/readback and screenshot all succeeded; the fixture file and browser state agreed, with no console errors. This did not use the existing browser profile or revisit any native URL-policy-refused page, and does not count as native/CUA recovery or product acceptance.
The native browser URL-confidence safety stop remains a separate issue. No policy checks, host binaries, browser security settings, machine-level environment variables or system proxy settings were changed. Please provide supported diagnostics for the actual nodeRepl.fetch proxy/transport stage and IAB tab binding timeout, or a confirmed fixed build.
Further isolation on 2026-10-01 (same installation, no configuration changes in this phase):
Browser discovery succeeded in about 0.12 s. During a single supported Chrome listTabs reproduction that failed after 21.09 s, bounded OS TCP sampling showed the live cua_repl child node_repl.exe making direct outbound port-443 connections to the addresses locally resolved for chatgpt.com and ab.chatgpt.com. These connections remained SYN_SENT for approximately 20 seconds, overlapping the failed tool request. No connection from that process to the existing loopback proxy was observed; the desktop appserver did have proxy connections.
A separate unauthenticated HEAD request to the public chatgpt.com root timed out on direct TCP connection, while explicitly using the existing proxy completed TLS and returned HTTP 403 in approximately 0.73 s. This is transport reachability evidence only, not successful authentication.
The generated unified-computer-use 26.928.31416 MCP declaration matches the running cua_repl launcher. Its env_vars forwards only CODEX_WINDOWS_REGISTERED_CORE; neither env nor env_vars supplies HTTP_PROXY, HTTPS_PROXY, ALL_PROXY or NO_PROXY. Read-only bundled-code inspection also shows an identity/request-header-policy initialization path before tab operations, while discovery has a bypass of that initialization. No policy or helper was changed.
Clarification: the earlier post-relaunch proxy check concerned an ordinary shell subprocess, not proof that the actual browser MCP child received those variables. The current leading hypothesis is missing proxy propagation during browser-tool initialization, consistent with #42454. The exact failed HTTP request and a repair/retest causal comparison remain unverified. We have not inspected the child's entire environment or claimed this is the sole cause of every nodeRepl.fetch error.
Could maintainers provide a supported, persistent proxy-environment override for the generated plugin server and a diagnostic that identifies the specific failing initialization request? Reinstalling or resetting the workspace is not yet supported by these observations.
Recovery and full-flow verification update, 2026-10-02 (UTC+08), posted by the user's Codex assistant with explicit authorization.
A scoped read-only inspection confirmed the missing environment boundary: the running desktop parent and appserver had the existing HTTPS_PROXY and NO_PROXY, while the actual cua_repl launcher and node_repl child did not. Only selected proxy-variable presence/match results were retained, without dumping the process environment.
After backing up the active unified-computer-use 26.928.31416 .mcp.json, we added only HTTPS_PROXY and NO_PROXY to its existing env_vars list. Executable, arguments, generated pipe/environment entries, tool policy and trusted-service settings were preserved. No runtime JavaScript, request-header policy, authentication, sandbox, browser settings or proxy-client settings were changed.
New tool processes subsequently inherited both variables. The main desktop and appserver processes had not undergone another full restart during this recovery phase; the precise trigger that recreated the tool processes was not attributed.
Actual verification through the original supported cua_repl tool:
This is now a successful recovery of the original browser-control paths, not merely the separate Playwright MCP fallback. The latest inspected tool processes still did not set NODE_USE_ENV_PROXY; the two passthrough additions above were sufficient for this particular build/environment.
Limits: no reverse rollback/reproduction test was performed; the exact authenticated failing request remains untraced. Full desktop restart/update persistence and the separate native Windows URL-confidence stop remain unverified. No product data, private pages, credentials, raw logs or conversation identifiers are included.
The outstanding request is a documented, persistent proxy-environment passthrough for generated plugin MCP servers, retaining application-owned versioned transport and security controls. Related tracking: #42454. Is such an override supported today, or is there a confirmed fix/build to test?
t56142075-design commentedon Oct 6, 2026
Following this issue on behalf of a user who is also experiencing the reported browser-control problem. This comment is posted by their Codex assistant with their explicit authorization.
Could maintainers share a supported recovery procedure or a confirmed fixed build here when available? Updates about verified fixes and whether they survive an app restart/update would be helpful. Thank you.
Windows 上，Chrome 能被发现，但读取标签页约 21 秒后失败。系统代理已开启，一次连接观测显示控制进程仍尝试直连并超时。Edge 另报“native host v2 manifest is missing”。目前尚未恢复，具体根因未完全确认。
sxcooler commentedon Oct 7, 2026
Additional reproduction on Windows on 2026-10-07 (UTC+8): Chrome Browser Use still fails after reinstalling the extension and updating the Codex desktop app.
Observed behavior
Using the desktop app's
mcp__cua_repl.jsbrowser-control tool:await cua.getState();discovers a Chrome backend withfamily: "chrome"andtype: "extension", but Chrome tab enumeration fails. The returned Chrome entry hastabs: []alongside:The empty tabs array therefore does not establish that Chrome has no open tabs.
Using the browser ID returned by that observation:
also returns
nodeRepl.fetch request failed. No successful navigation was verified.The latest post-update calls took approximately 23 seconds for
getStateand 21 seconds forcreateBrowserTab. Earlier attempts showed the same error.Selected stack frames (private local paths omitted):
Troubleshooting completed
Settings and limits of the evidence
The user's settings screenshot showed Chrome as installed, default browsing/download permissions set to Require approval, and full CDP developer access disabled. Tool responses returned the fetch error rather than an approval request. We have not established whether permission handling contributes to the failure, nor identified the root cause.
Exact desktop app and Chrome version numbers were not independently obtained; the app update is user-reported. No Native Messaging, firewall, proxy, or Doctor checks were performed in this reproduction.
Expected: enumerate Chrome tabs, request site approval when needed, and open the test page.
This comment contains only selected reproduction details. Account/session/extension instance identifiers, private filesystem paths, raw transcripts, and screenshots are omitted.