[Windows app 26.903.8094.0] In-app browser discovery fails with nodeRepl.fetch request failed after cua_repl reset

What version of the Codex App are you using?

• Installed Windows package, queried locally: OpenAI.Codex 26.903.8094.0.
• Desktop app-server executable version, queried locally: codex-cli 0.153.4.
• Browser control tool: mcp__cua_repl, documented cua API.

What platform is your computer?

Windows x64. Observed on 2026-09-09.

What issue are you seeing?

The app reported two open in-app browser tabs and a selected loopback preview URL. The user explicitly mentioned the Browser tool, but even the initial inventory call failed:

await cua.getState();

The result was:

{
  "apps": [],
  "browsers": [],
  "errors": [
    "Browsers: Error: nodeRepl.fetch request failed"
  ]
}

The tool then emitted Error: nodeRepl.fetch request failed. Recent attempts took approximately 22–24 seconds each.

The empty browser array is returned alongside an inventory error; it should not be interpreted as evidence that the user has no browser tabs open. No browser or tab handle could be obtained during these failed attempts.

What steps can reproduce the bug?

Sequence observed in this affected session (not a fresh-install or cross-machine reproduction):

1. Have the in-app browser open with a local preview selected.
2. Ask the agent to inspect that browser, including an explicit Browser mention.
3. Call the documented inventory API await cua.getState();.
4. Observe the error above instead of browser/tab inventory.
5. Call mcp__cua_repl.js_reset. The tool reports js kernel reset.
6. In the fresh session, execute exactly one first-use API call: await cua.getState();.
7. Initial tool documentation is returned, but browser inventory again fails with the same error.

Repeated inventory attempts and one documented REPL reset did not restore the connection. A full application restart/reinstall was not tested for this occurrence.

Control checks and limits

• An independent HTTP check of the loopback preview returned HTTP 200 and its expected page title. This confirms that the web server responded, not that the current browser rendering was visually verified.
• App-supplied UI context reported two in-app browser tabs and the selected preview URL. Because browser-control inventory failed, current page contents could not be independently read or screenshotted through that tool.
• Earlier in this task, the same in-app-browser workflow could open, inspect and screenshot the preview. The trigger for the later connection failure is unknown.
• The failing operation was inventory, before any navigation or page interaction. It did not return a URL-policy denial or command-approval rejection.
• No proxy, firewall, browser profile, credentials, or security settings were modified to diagnose this browser failure. Proxy/environment inheritance and the underlying transport failure have not been established as causes.

What is the expected behavior?

The tool should discover the available in-app browser and tabs, or provide an actionable diagnostic identifying which connection/setup stage failed. A documented reset should either re-establish the connection or clearly state what additional recovery is needed.

Related reports

• #19519: same error in the in-app browser, but that report could list/read tabs and failed during navigation. This occurrence fails at initial inventory.
• #43787: similar error persisting after a fresh runtime, but on macOS with external Chrome. No shared root cause is asserted.

This report contains no personal filesystem paths, account identifiers, private site domains, credentials, screenshots, or raw session logs.

Start with the documented cua.getState() inventory call on Windows, then reproduce the sequence through mcp__cua_repl.js_reset and a fresh first-use call. Investigate the nodeRepl.fetch request failure and the empty browser inventory; done means browser and tab discovery works after reset or the tool reports an actionable connection-stage diagnostic.