Repository navigation
[Windows][Codex App 26.930.7945.0] Chrome discovered but tab enumeration and creation fail with nodeRepl.fetch request failed #51363
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Installed Windows package version: 26.930.7945.0 (OpenAI.Codex, read from Get-AppxPackage; About dialog was not checked).
What subscription do you have?
Not collected for this report.
What platform is your computer?
Windows 11 Home, Chinese edition, x64; OS version 10.0.26200.
Google Chrome installed binary version: 154.0.8037.98.
Reproduced on October 6, 2026, in a local Codex desktop chat.
What issue are you seeing?
Codex discovers Chrome as an extension-backed browser, but cannot enumerate its tabs or create a new tab. Browser operations fail after approximately 21–22 seconds with:
nodeRepl.fetch request failed
This blocks a simple user request to open a public website in Chrome.
The initial await cua.getState() returned Chrome provider metadata, then an inventory error:
{
"apps": [],
"browsers": [
{
"family": "chrome",
"id": "3",
"name": "Chrome",
"type": "extension",
"tabs": []
},
{
"id": "2",
"name": "Codex In-app Browser",
"type": "iab",
"tabs": []
},
{
"id": "1",
"name": "Codex MCP Apps",
"type": "mcpapps",
"tabs": []
}
],
"errors": [
"Browser 3: Error: nodeRepl.fetch request failed"
]
}Chrome profile name and extension/session identifiers have been omitted. The empty tab array is returned alongside an error, so it does not establish that Chrome actually had no tabs. The other browser providers were listed; their navigation functionality was not tested.
Relevant redacted stack frames from the initial failure:
Error: nodeRepl.fetch request failed
at <TEMP>\kernel.js:1595:16
at Object.settle (<TEMP>\worker-runtime.js:396:5)
at <TEMP>\kernel.js:1871:11
at handleInputFrame (<TEMP>\worker-runtime.js:418:7)
at Socket.<anonymous> (<TEMP>\worker-runtime.js:434:9)
What steps can reproduce the bug?
- In the Windows Codex desktop app, ask the agent to test the Chrome connection.
- Call
await cua.getState(). Chrome appears in the inventory as an extension-backed provider, but tab enumeration fails with the error above. The observed tool duration was 21.789 seconds. - Explicitly mention
@Chromeusingplugin://browser@openai-bundled?browserFamily=chromeand ask it to open Baidu (https://www.baidu.com). - Refresh browser discovery using
await cua.listBrowsers(). This succeeds and reports Chrome with current provider ID"4"and the same extension instance as before. - Use the newly discovered ID to create a tab:
await cua.createBrowserTab("4", "https://www.baidu.com");- This fails again with
nodeRepl.fetch request failedafter 21.326 seconds. No successful tab creation or page load was confirmed.
The IDs above are observed session values, not stable IDs to reuse in another session. Use the current Chrome ID from discovery when reproducing.
What is the expected behavior?
When the connected Chrome extension is discovered, Codex should be able to enumerate its tabs and open a new tab at https://www.baidu.com.
If the extension transport is unavailable, the error should identify the failure and provide a supported recovery step instead of only exposing a generic fetch failure.
Additional information
Two separate intermediate errors occurred before the final attempt:
- Reusing the previous provider ID
"3"returnedBrowser is not available: 3; discovery then returned ID"4". - Passing
{ visible: true }tocreateBrowserTabreturnedCapability is not available: visibility. Removing that option and using the current provider ID still produced the fetch failure above.
These intermediate errors were corrected before the final failed tab request. Their relationship to the transport failure is unknown.
Related reports: #44383, #46095, #50837, and #50675 (Edge).
This report adds the exact current Windows app/Chrome versions, successful provider discovery, and a failed tab-creation attempt using the freshly discovered provider ID. No proxy/TLS/root-cause conclusion is established by the evidence collected here.
Activity
github-actions commentedon Oct 6, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Isla0721 commentedon Oct 8, 2026
I am experiencing the same issue on Windows 10.
My environment:
Symptoms:
"nodeRepl.fetch request failed"
"Chrome is detected, but its automation bridge isn't responding."
I also confirmed that the official bundled plugins are installed and enabled:
The problem started after a Codex update. Chrome/Computer Use worked normally before the update.
This appears to be a persistent Windows Browser/Computer Use bridge issue rather than a missing plugin.
I would appreciate it if you could investigate this issue on Windows 10.
benzhi608-coder commentedon Oct 8, 2026
Additional Windows reproduction and a request for supported host-level diagnostics.
Environment: Codex desktop 26.1002.52244, build 13536; installed Windows package 26.1002.7124.0, x64. The app updater reports up_to_date. Both Chrome and Edge are discovered as extension-backed providers.
Observed through the supported browser API:
Bounded read-only investigation of the installed browser-service 0.1.1 and its runtime wrappers:
Please provide:
No account switch, reinstall, private browser RPC, generated-config patch or security-policy weakening was used for this investigation. Usernames, paths, chat IDs, browser profiles, extension IDs, raw logs and credentials are omitted.
NicolaChen commentedon Oct 9, 2026
Same root cause as #52472 (the macOS case, analyzed in depth). Summary of the mechanism found there — it matches the
{"family":"chrome","type":"extension","tabs":[]}inventory shown above:The desktop app revokes the browser route for the active conversation almost immediately after capturing it: it hands the "browser use host" to a
client-new-threaddraft session and marks the user's session asended(374 ms in the macOS logs; reproduced across restarts and conversation types). The extension-backed browser therefore never becomes usable for a real conversation, while the IAB backend can still respond — exactly the asymmetry seen here (Chrome discovered, tab enumeration/creation fails,nodeRepl.fetch request failed).Full evidence, code localization and cross-version comparison: #52472
benzhi608-coder commentedon Oct 9, 2026
Follow-up: browser request-header policy initialization fails again after a real desktop restart.
Observed on Windows with installed package version 26.1002.7124.0. Earlier browser operations had succeeded after TUN was enabled, including after a previously confirmed account switch and app restart. Those successes did not establish durable recovery.
After another confirmed Codex desktop app restart, with the same package:
The inspected desktop logs did not expose a corresponding policy request status, timeout stage, or response detail. We have not disabled the policy gate or changed credentials, permissions or proxy rules.
Is there a supported way to obtain request-level diagnostics for this policy initialization failure (request ID, response category or timeout stage), without exposing credentials or bypassing the policy? The current evidence does not justify treating extension reinstallation or TUN alone as a durable fix.
benzhi608-coder commentedon Oct 10, 2026
Follow-up: browser request-header policy failure, recovered on a supported retry, with diagnostic detail loss
Environment
Observed on 2026-10-10, approximately 14:10-14:13 UTC
"Unable to load browser request-header policy. Retry the browser command."
Read-only source findings from the exact installed bundle
These are static error-propagation/deadline observations. They do NOT establish the unique trigger of this incident, nor prove a disabled gate, bad account, TLS failure, or network-provider fault.
Transport comparison and log limits
Request
Please expose a supported, redacted browser-policy diagnostic that retains:
Please also review deadline/retry/cancellation coordination and preserve these details in the existing error path while keeping policy enforcement intact. The current generic error makes different failure modes indistinguishable and encourages ineffective reinstall/account/network troubleshooting.
No credentials, account identifiers, business URLs, screenshots, response bodies, or local user paths are included in this supplement.
benzhi608-coder commentedon Oct 12, 2026
Follow-up: bounded host-response diagnostics and a compressed-transport comparison (Windows, October 12, 2026)
This separates the observed failure stage from the ultimate network/header cause. It is not evidence of a policy denial, an account problem, or an SD-WAN fault.
A temporary, consented diagnostic observed the original in-flight requests after the SDK had already reported failure. Six terminal host results returned "nodeRepl.fetch response read failed" after 30,002–30,003 ms. These are six selected observations on the initialization route, not a unique correlation to the failed policy gate. They show that the local request/result bridge progressed for those requests; they did not remain indefinitely before a host result.
Read-only analysis of the pinned local host binary identified the response-body collection error branch constructing that fixed error string and discarding the underlying reqwest error. The existing JavaScript bridge forwards the error text without a structured cause. We still do not have the original HTTP status, received byte count, timeout flag, or error chain. Static analysis is not a captured native stack or proof of an exact timer type.
The candidate changes only the existing Statsig initialization POST transport: it requests Brotli through the same host.fetch and performs bounded local decoding. The original SDK, feature-gate checks, policy decisions, timeouts and retries are preserved; malformed input fails closed. An independent review of the exact candidate implementation and isolated SDK tests verified the 10 MiB bounds on compressed and decoded bodies and the fail-closed cases; the successful live requests alone do not prove those bounds. No alternate endpoint, authentication change or policy bypass is introduced.
Candidate: browser inventory completed in 3.97 s. At the helper boundary, the response had HTTP 200 and 689,699 compressed bytes, decoded to 5,215,728 bytes. The Content-Encoding indication was absent there; bounded Brotli decoding succeeded. A new public page was then created and read successfully.
After restoring the exact original file and resetting the current chat browser tool, inventory failed again with "Unable to load browser request-header policy. Retry the browser command." after 20.51 s.
Under separate consent for retained use, the same candidate passed again: inventory 3.75 s; HTTP 200, 685,954 compressed bytes, 5,215,355 decoded bytes; the same absent-encoding branch. Public-page reading passed and the test tab was closed. The candidate remains a pinned local workaround, not an official fix or an automatic upgrade patch.
The paired comparison supports the usefulness of this transport change in the tested environment, but does not establish a unique root cause. The missing encoding indication was observed only at the helper boundary: we cannot yet distinguish origin behavior from an intermediary or local response-header forwarding. We cannot infer why the original body read failed from the compressed success.
A later desktop process started after adoption also passed Chrome enumeration and public-page reading. That check observed HTTP 204 passthrough, not a fresh Brotli response or proven cold initialization. Account switching, Cockpit launch provenance, Edge and long-term reliability remain unverified.
Could the supported diagnostic path preserve sanitized error category/timeout flags, status when available, bytes received and response-encoding presence at the host boundary, correlated to the failed request? Also please check that the authenticated-fetch response body and encoding metadata remain consistent across forwarding. These fields would distinguish incomplete upstream/body transfer from local forwarding or decoding problems without exposing policy contents, credentials or browsing data.