[Windows][Codex App] Browser Use and Computer Use both fail at initialization with `nodeRepl.fetch request failed`

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.

1. Start Codex Desktop 26.903.61454 on Windows.
2. Create a completely fresh local Codex session.
3. Do not open or navigate to any test website.
4. Attempt to initialize Computer Use:

cua.initialize()

5. Alternatively, attempt to read Browser/CUA state:

cua.getState()

6. 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:

• #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.
• #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.
• #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.

Start by reproducing cua.initialize() and cua.getState() on Windows, then inspect the node_repl process, relevant named pipes, and the bundled browser-client.mjs that contains setupBrowserRuntime. Compare the shared Browser/Computer Use initialization path with the diagnostic results and related issues. Done means both operations enumerate supported applications and browsers without the generic nodeRepl.fetch request failed error.