Repository navigation
Windows Codex browser control fails: nodeRepl.fetch request failed #46095
Description
Problem
On Windows, the Chrome extension panel loads, but Codex cannot enumerate or control browsers. Reproduced September 17, 2026:
await cua.getState();
{"apps":[],"browsers":[],"errors":["Browsers: Error: nodeRepl.fetch request failed"]}
The call takes about 21–23 seconds. The same runtime also reports fetch failures for ab.chatgpt.com/v1/initialize and /v1/rgstr.
Environment and troubleshooting
Windows 11 Pro 25H2, build 26200.9445; Codex desktop 26.908.9136.0 (versions checked September 15). User has restarted Chrome and Codex, reinstalled the extension, and tried a new chat. Earlier official checks passed for extension enabled in Chrome Default profile and native-host registration.
A local HTTP proxy is required; no working proxy-free network is available. HTTP_PROXY/HTTPS_PROXY/ALL_PROXY point to the local proxy; NO_PROXY includes localhost. No custom CA bundle was configured.
Network evidence
On September 15, separate Python probes through that proxy completed CONNECT and verified TLS for chatgpt.com, ws.chatgpt.com, and o33249.ingest.us.sentry.io. These probes do NOT verify the authenticated WebSocket or desktop browser-control runtime.
Feedback failure
After reproduction, /feedback showed "upload unconfirmed". At 2026-09-15 08:14:42 UTC, the desktop log recorded feedback/upload error -32603: upload to o33249.ingest.us.sentry.io failed with "unexpected EOF during handshake". Receipt is unconfirmed. A private feedback reference can be supplied to maintainers through an appropriate channel.
Request
OpenAI support referred this case to GitHub. Please triage to the desktop/browser-extension component and provide supported diagnostics for the actual proxy/TLS path used by nodeRepl.fetch and the feedback client. The existing evidence does not establish a missing CA or a proxy root cause.
Only minimal diagnostic details are included here; unrelated business data, full session transcripts, credentials and URL query parameters are omitted.
Activity
github-actions commentedon Sep 17, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
das23f commentedon Sep 17, 2026
Additional update: the connection problem persists after updating the desktop app.
The side-panel DevTools also show a blocked data: font (font-src), blocked string evaluation (script-src), and Statsig warnings. I have not confirmed whether these messages are related to the browser-control failure.
Please advise on the supported next diagnostic steps.
yangfangzhang0-lab commentedon Sep 17, 2026
May I ask if the issue has been resolved?
xilin2020 commentedon Sep 26, 2026
Additional Windows in-app browser (IAB) reproduction, tested on 2026-09-26. This shares the reported error, but I cannot establish that it has the same root cause as the Chrome-extension case.
Versions and impact
Minimal reproduction and observed results
await cua.getState();.{"apps":[],"browsers":[],"errors":["Browsers: Error: nodeRepl.fetch request failed"]}Before the upgrade,
cua.getTab({url: "https://example.com/"}, {browser: "iab"})once returned a multiple-match list with real tab IDs. Selecting one returned ID usingcua.getTab(id, {browser: browserId})then timed out after approximately 44 seconds and reset the kernel. Thus tab enumeration can partially work while page reading still fails.Diagnostic observations (not a confirmed root cause)
On 26.917.9434.0, desktop logs for the affected task repeatedly reported:
Related page-mapping logs showed the request
conversationIdreferring to the current task, while the pagerouteKeybelonged toclient-new-thread:<redacted>. This persisted after manually reopening the task/page and attempting the supported task-navigation/open-panel actions. I have not yet established whether the same routing detail persists on 26.924.1866.0; the fetch failure itself does.Network troubleshooting already performed
codex doctorinitially reportedrespect system proxy: disabled.codex doctor --enable respect_system_proxy --jsonreturned HTTP 101 in about 1.8 seconds.features.respect_system_proxy = trueoption, with backup and a semantic config comparison confirming that this was the only setting change.codex doctor --jsonconfirmed the option enabled and a successful Responses WebSocket handshake (HTTP 101, 1831 ms); HTTP reachability also passed.Request
Please triage the IAB session-route/transport failure and advise a supported diagnostic or repair procedure. Restarting, reopening the task/tab, and upgrading the desktop app have not resolved it. A separate
file://URL-policy denial was also observed earlier, but this report reproduces on ordinary HTTPS and does not require any policy bypass.Only sanitized diagnostic observations are included; no credentials, session IDs, local paths, project data, full logs, or conversation transcripts are attached.
VidyFoo commentedon Sep 27, 2026
This provides a successful Chrome-control test after a routing change. We did not verify the separate Windows IAB or feedback-upload failures discussed 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.yangkyle66-ops commentedon Oct 10, 2026
Additional reproduction on Windows with Microsoft Edge, checked on October 10, 2026.
Versions
Expected and actual behavior
The browser-control tool discovers the Edge extension instance, but cannot enumerate or control tabs. Both
browser.tabs.list()andbrowser.user.openTabs()return:Each of those two calls took approximately 21 seconds after reinstalling the extension.
browser.nameSession()also failed with the same message. Browser discovery itself returned an Edge browser with typeextension.Diagnostics and recovery already attempted
The bundled official diagnostics passed:
scripts/chrome-is-running.js --browser edge --check: Edge running.scripts/installed-browsers.js --json: Edge installed.scripts/check-extension-installed.js --browser edge --json: installed and enabled in the selected Default profile.scripts/check-native-host-manifest.js --browser edge --json: host name, registry pointer, and permitted extension origins correct. Rechecked after reinstalling; still passed.Opening a window in the correct profile and recreating the control session did not resolve the failure. The extension was reinstalled; browser discovery then reported a different extension-instance identifier, and a new native extension-host process started. Edge and Codex were both restarted, verified by new main processes. The user subsequently tested a new Codex chat and reported that it also failed.
The underlying cause is not established. These checks do not prove that the authenticated browser-control transport works or identify a proxy, TLS, firewall, website-permission, or version-compatibility cause.
Please triage the Windows desktop/Edge browser-control transport and advise on supported diagnostics for the failing
nodeRepl.fetchpath. This comment contains only the version information, error text, and diagnostic results; no raw logs, session transcripts, account details, or local user paths are attached.