Repository navigation
[Windows][Codex App] Browser Use and Computer Use both fail at initialization with nodeRepl.fetch request failed #44500
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex App version: 26.903.61454. Release date shown in the app: September 8, 2026. Additional version information: ① Windows MSIX package: 26.903.8094.0. ② Bundled Codex CLI: 0.153.4. The app's "Check for Updates" action reports: ChatGPT is up to date.
What subscription do you have?
ChatGPT Pro 20x
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
Browser Use and Computer Use both fail at the common initialization/discovery stage on Codex Desktop for Windows.
The failure reproduces before any website is opened or controlled.
For Browser Use:
cua.getState()
Elapsed time: approximately 21–22.5 seconds
apps: []
browsers: []
error: nodeRepl.fetch request failed
For Computer Use:
cua.initialize()
Elapsed time: approximately 21.3 seconds
apps: []
browsers: []
error: nodeRepl.fetch request failed
The error stack includes:
Pipe.onStreamRead
The failure prevents Codex from enumerating or attaching to the in-app browser, Chrome, or native Computer Use applications.
Chrome provider discovery succeeded during an earlier test, but attempts to read existing Chrome tabs with openTabs() failed with the same nodeRepl.fetch request failed family of errors.
This is not specific to any website. The failure happens before page navigation, DOM access, input, or other page interaction.
The same Windows environment previously supported Codex in-app Browser Use, Chrome control, and Computer Use successfully approximately 1–2 months ago.
What steps can reproduce the bug?
A private website or application is not required to reproduce this.
- Start Codex Desktop
26.903.61454on Windows. - Create a completely fresh local Codex session.
- Do not open or navigate to any test website.
- Attempt to initialize Computer Use:
cua.initialize()
- Alternatively, attempt to read Browser/CUA state:
cua.getState()
- Wait approximately 21–22 seconds.
Observed result:
apps: []
browsers: []
nodeRepl.fetch request failed
The stack includes:
Pipe.onStreamRead
The issue has also been reproduced after all of the following:
- creating a fresh Codex session;
- resetting the CUA/JavaScript kernel;
- fully exiting and restarting Codex Desktop;
- creating another fresh session after the Desktop restart;
- independently restarting the bundled Chrome
extension-host.exe.
None of these restored Browser Use or Computer Use.
Session/context information:
- The bug reproduces in a brand-new session.
- It can occur on the first Computer Use / Browser state operation.
- Token usage and context-window pressure therefore do not appear relevant.
- Session ID can be provided privately if required.
What is the expected behavior?
cua.initialize() should successfully initialize the Computer Use runtime and return the available supported applications and browser backends.
cua.getState() should successfully enumerate available browser/application state.
After initialization, Codex should be able to:
- use the in-app browser;
- discover and control supported Chrome tabs;
- expose supported native Windows applications through Computer Use.
If initialization fails, the error should expose the underlying failing component or actionable cause instead of only:
nodeRepl.fetch request failed
Additional information
Network / proxy environment
Clash is used on this Windows machine.
Both of the following are continuously enabled:
Windows system proxy: ON
TUN / virtual network adapter mode: ON
These settings were also used when Codex Browser Use, Chrome control, and Computer Use worked successfully in the past.
This differs from #44364, where the reported failure occurs with TUN disabled and enabling TUN restores browser control. In this reproduction, TUN is already enabled and the failure persists.
Diagnostic results
codex doctor completed its Desktop diagnostics.
The following checks passed:
Desktop app-server initialization
Codex installation
configuration
authentication
state database
active provider HTTP reachability
codex doctor does not appear to test Browser RPC readiness directly, and Browser/CUA calls still fail.
The Doctor command returned exit code 1 for unrelated diagnostics involving:
TERM=dumb
some unavailable/missing rollout files
There is currently no evidence that these are responsible for the Browser/CUA failure.
Process/runtime observations
After a full Codex Desktop restart, the following components were newly started and remained alive during the failure:
app-server
code-mode-host
node_repl
The Chrome extension-host.exe was also independently restarted. This did not restore functionality.
The failing node_repl.exe process remained alive after the approximately 21-second failure.
Relevant Codex named pipes exist, including names in these families:
codex-browser-use-*
codex-computer-use-*
codex-ipc
The relevant bundled helper files also exist.
No direct evidence was found for:
PATH NOT FOUND
ACCESS DENIED
ECONNRESET
ECONNREFUSED
app-server queue full
Therefore, process existence and pipe existence are confirmed, but Browser/Computer Use RPC readiness is not.
Bundled Browser client
The Browser and Chrome bundled copies of browser-client.mjs for this installation are byte-identical:
version: 26.903.61454
length: 150615 bytes
SHA-256:
3FDE147AA3779BFC112AA91CBAB60FDE99DC494F7DE76C3766FFEB9B1DC7CCAE
The current implementation contains setupBrowserRuntime and does not reference the older __codexNativePipe mechanism, so older native-pipe-injection diagnostics do not apply directly to this version.
Related open issues
I searched existing open issues before filing.
There is symptom overlap with:
- Windows: Chrome control fails with nodeRepl.fetch request failed #44135 — Windows Chrome control fails with
nodeRepl.fetch request failed. In that report, in-app browser tab listing succeeds; in this reproduction, IAB discovery also fails. - [Codex app][Windows] Chrome control fails without TUN; verified cua_repl launch.mjs proxy workaround #44364 — Windows Chrome control/proxy issue where enabling TUN restores control. In this reproduction, system proxy and TUN are already enabled continuously and the failure persists.
- Windows Computer Use is enabled, but native desktop app enumeration is empty #44393 — Windows native Computer Use application enumeration is empty, while Browser Use remains functional. In this reproduction, both native Computer Use initialization and Browser/IAB discovery fail.
Because this reproduction affects both Browser Use and Computer Use at their shared initialization/control layer, it does not appear to be fully covered by those reports.
No private URLs, credentials, account identifiers, private page content, or application data are required to reproduce this issue.
Activity
github-actions commentedon Sep 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
StIssac commentedon Sep 18, 2026
Current Windows + Edge recurrence (September 18, 2026)
Reproduced on Windows with Codex Desktop
26.915.3509.0, CUA runtime26.915.31029, and the current Edge extension1.26.901.11451. Bothcua.getState()and directcua.getTab()calls time out after about 30 seconds and reset the kernel, including after restarting Codex.Please treat this as a current regression and investigate CUA initialization readiness, Edge host lifecycle, and actionable error reporting. Private task IDs and logs are available through the existing support case.
StIssac commentedon Sep 18, 2026
Follow-up: the same failure also blocks the built-in browser
Immediately after the Edge recurrence above, the user opened an existing Codex in-app browser tab and asked the agent to continue through that built-in browser.
Two consecutive attempts to bind the already-open in-app browser tab failed:
No page content was read and no browser action was performed. The second call was the single bounded recovery retry; the agent then stopped rather than entering another retry loop.
This shows that the current failure is not limited to the Edge extension path. The visible in-app browser can be loaded while the CUA tool still cannot bind to its tab. Please include the in-app-browser transport/initialization path in the investigation.
StIssac commentedon Sep 18, 2026
Post-restart reproduction on Windows confirms this is now the IAB session-route failure, not the proxy-only failure.
Environment:
What was tested:
The desktop log gives the product-side cause:
So the proxy workaround is present and verified syntactically, but it cannot repair the missing IAB route. This matches the route-loss family reported in #45028, #46100, and #46106.
This blocks real work: the visible built-in browser is usable by the human, but the agent cannot bind or create an IAB tab, so it cannot create and securely save a Codeup credential. Please route this to the Codex Desktop Browser/Computer Use owners and provide a fixed build or supported route re-registration mechanism. Reinstall/restart/app-data reset loops are not a recovery for this logged failure.
StIssac commentedon Sep 18, 2026
Additional lower-layer reproduction: after the IAB route failures above, the user explicitly invoked the bundled @computer / Computer Use plugin. Following the bundled computer-use SKILL.md, initialization of the native Windows layer via import("@oai/sky") timed out after about 30 seconds and reset the JS kernel. I then ran js_reset and repeated the documented initialization once; it timed out again and reset the kernel.
The bundled recovery guide says to stop after this reset-and-retry sequence and report that the Windows Computer Use helper may have failed. Therefore both supported control paths are unavailable in this build: browser CUA fails with the missing ChatGPT browser route, and direct Windows Computer Use cannot initialize its @oai/sky helper.
StIssac commentedon Sep 18, 2026
A full Windows reboot did not recover any of the three supported control paths on Codex Desktop 26.915.3509.0 with unified-computer-use 26.915.31029.
The generated unified-computer-use manifest enables only the browser surface and omits the trusted Sky service, despite the bundled @oai/cua-repl README supporting browser, computer, or browser,computer and stating that Desktop supplies Browser and Sky services. Invoking @computer did not regenerate or activate that documented configuration.
A narrowly scoped backup-and-repair of those fields was prepared, but Codex auto-review rejected the persistent local-control configuration change. The product therefore neither generates the documented Computer configuration nor permits the targeted correction through the normal approval path.
Please provide a fixed build or a supported UI path that re-registers IAB routing, restores Edge RPC, and activates the Computer/Sky service when @computer is invoked. Reinstall/restart/app-data-reset loops do not address these concrete failures.
StIssac commentedon Sep 20, 2026
Fresh regression check after updating unified-computer-use from 26.915.31029 to 26.915.31945:
The available update therefore did not fix the missing IAB route, Edge RPC failure, or missing Computer/Sky registration. Please keep this incident open against 26.915.31945 and provide a build that restores the documented control paths.
KrisZhao23 commentedon Sep 22, 2026
Also reproduced on Windows native with:
Both
node_replandcua_replfail during MCP initialization with:MCP startup failed: handshaking with MCP server failed:
connection closed: initialize response
The bundled runtime was verified byte-for-byte against a pristine signed Store package. Full CDP access, reinstalling the plugins, and restarting the app did not resolve it.
Feedback session ID:
01a0c7f8-e7ae-7a70-ac21-0c3afdd8e19c
KrisZhao23 commentedon Sep 22, 2026
Update: the external Chrome control path initialized successfully in a later task without an app update. This may be intermittent or task/session-scoped. The built-in browser path has not yet been reverified.
VidyFoo commentedon Sep 27, 2026
This is relevant only to the Chrome fetch-failure symptom mentioned here. We did not verify recovery of Windows native Computer Use or the separate IAB session-route failure.
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.