Repository navigation
[macOS, 26.901.51231] Chrome is discovered, but browser-control calls fail with nodeRepl.fetch request failed #43787
Description
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT desktop / Codex-integrated app 26.901.51231 (build 8109).
What subscription do you have?
Pro 5x
What platform is your computer?
macOS 26.6, Apple Silicon (arm64). uname -mprs: Darwin 25.6.0 arm64 arm.
What issue are you seeing?
The bundled Browser plugin discovers Chrome successfully, but basic control requests consistently fail with:
nodeRepl.fetch request failed
Tested operations:
| Operation | Result |
|---|---|
| Browser runtime initialization and Chrome discovery | Succeed |
| Chrome documentation retrieval | Succeeds |
| chrome.nameSession(...) | Fails |
| chrome.tabs.list() | Fails |
| chrome.user.openTabs() | Fails |
Environment details:
- Google Chrome: 152.0.7977.76
- Bundled Browser plugin: 26.901.51231
- ChatGPT Chrome extension: 1.26.901.11451 observed before reinstall
The Chrome extension side panel loads. Opening https://stripe.com through normal Chrome UI interaction also succeeds. The reported control failure occurs before navigating to that website.
What steps can reproduce the bug?
- Open Chrome with the ChatGPT extension enabled and the desktop app running.
- In a local desktop chat, ask the agent to use Chrome to open https://stripe.com.
- Initialize the bundled Browser runtime and select Chrome using the documented API.
- Run the following operations separately:
const chrome = await agent.browsers.get("chrome");
nodeRepl.write(await chrome.documentation()); // succeeds
await chrome.nameSession("Chrome connection test"); // fails
await chrome.tabs.list(); // fails independently
await chrome.user.openTabs(); // fails independentlyThe same error remains after initializing the Browser runtime from scratch in a fresh Node REPL session. This is not limited to reusing a stale browser handle.
What is the expected behavior?
Codex should be able to list and control Chrome tabs after discovering the browser. If a request fails, the error should identify the failing component or expose an actionable underlying cause.
Additional information
Diagnostics completed:
- Chrome is installed and running; the extension is installed and enabled.
- The bundled native-host manifest check passes, including the host name and allowed extension origins.
- The native-host executable exists and is running.
codesign --verify --strictpasses for the native host, and its signature identifies OpenAI OpCo, LLC.
Recovery attempts that did not restore control:
- Opening a new Chrome window in the profile selected by the bundled diagnostic tool.
- Disabling and re-enabling the ChatGPT Chrome extension.
- Reinstalling the Chrome extension.
- Re-selecting Chrome after the old browser connection became unavailable.
- Initializing the runtime from scratch and retrying in a fresh Node REPL session.
Desktop logs also contain this warning during the diagnostic period:
browser-use native pipe rejected socket peer reason=missing-code-signing-identity
The warning does not identify the rejected peer. Because the installed native host passes signature verification, I cannot attribute this warning to that executable or confirm that it causes the control failure. Proxy inheritance has not been verified as a cause either.
Related: #43385 reports highly similar behavior on the same app/plugin version. This report adds a reproduction where the native host passes OpenAI signature verification. #21713 describes a potentially related proxy issue in an older version; I have not established that it is the same cause here.
This report omits account identifiers, session IDs, local usernames, private URLs, credentials, and raw log files.
Activity
github-actions commentedon Sep 8, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
HaoGodG commentedon Sep 9, 2026
I can reproduce the same Chrome control failure on an Intel x86_64 Mac, which may help confirm this is not Apple-Silicon-specific.
Environment:
26.901.51231, build81090.153.4152.0.7977.761.26.901.11451x86_64The Chrome extension backend is successfully discovered as:
type=extension, browser id=2After explicitly selecting that backend:
createBrowserTab("2", "https://example.com/")hangs and fails after approximately 30 seconds.
I performed a full Chrome + Codex cold restart and also reset
/tmp/codex-browser-use. The failure remained.Additional validation:
26.901.51231.ChatGPT for Chromenative host exists and isx86_64.codesign --verify --deep --strictpasses.2DC432GLL2.lsof/netstatconfirm the extension-host owns a live Unix socket.browser_use_iab_backend_startup_ready.getInforequest completes successfully.The failing
createBrowserTab()call did not requestvisibilityorviewport, so the earlierCapability is not available: visibilitymessage does not appear necessary to reproduce the main failure.Historical logs from failed runs also contained:
No ChatGPT browser route is available for browser sessionroute window is not live hasWindowState=falseIpcRouter Socket error ... EPIPEI cannot determine whether the ~30s stall occurs in Desktop → extension-host routing, extension-host → Chrome extension communication, the actual Chrome operation, or the response path.
Current assessment: the failure occurs after backend discovery but before successful Chrome browser-control RPC completion.
No reliable workaround found; cold restart and socket reset did not restore Chrome control.
dcmf6kms8k-cpu commentedon Sep 11, 2026
Additional macOS reproduction on desktop 26.903.71938, observed 2026-09-11. Posting here to consolidate the similar Chrome-control failure rather than create a duplicate. This occurrence also affects in-app browser control; a shared root cause has not been established.
Uploaded feedback/session ID:
01a05d4e-06d1-7400-b59d-0016da46a3d7(the desktop UI confirmed feedback submitted).Environment and checks
Public-page reproduction
Only https://example.com is needed; no authenticated page, upload, or business API is involved.
Observed tool timings/results:
nodeRepl.fetch request failed.js execution timed out; kernel reset, rerun your request.Browsers: Error: nodeRepl.fetch request failed. This is an inventory failure, not evidence that all browsers are closed.No title read or link-click verification succeeded. Earlier standalone browser discovery sometimes succeeded while tab operations failed.
Targeted IAB log observations
On 2026-09-11 at 03:44:11 UTC, getInfo for the durable task ID reports:
No ChatGPT browser route is available for browser session <durable-task-id>At 03:44:12–03:44:13 UTC, subsequent records show webview created/attached, host opened page, and createTab mapped page to tab. In the mapping record:
client-new-thread:<temporary-id>identifier.Thus a page object was created even though the tool timed out; navigation completion/readback remains unverified. Please confirm whether this temporary/durable mapping is expected and whether it relates to route lookup failure. It is a diagnostic lead, not a claimed root cause. Related routing symptoms also appear in #44338, but that report concerns a different user-visible failure.
Recovery already tried
Desktop update/restart, documented CUA reset, task navigation, a fresh independent task plus foreground comparison, and a targeted native-host restart (Chrome respawned it) did not restore control. No manual re-signing, socket deletion, security weakening, app database edits, or compiled-app patches were performed.
Please advise on a supported diagnostic/fix for browser RPC and session-route recovery. Repeated restart/login loops leave autonomous workflows blocked. This public comment excludes raw logs, private URLs, credentials, local usernames, and business data.
yxspace commentedon Sep 11, 2026
Adding another macOS reproduction from mainland China. Browser control worked reliably on this machine until roughly the last two days, then stopped working without the Chrome control toggle being disabled.
Environment
26.903.71938(build8576)26.6.2, Apple Silicon (arm64)153.0.8010.37152.0.7977.84, likely before the Chrome update/relaunch1.26.901.11451, installed and enabled in the normal logged-in Chrome profilebrowser,chrome, andunified-computer-useplugins:26.903.71938, installed and enabledChatGPT for Chromenative-host process is runningcodesign --verify --deep --strictsucceeds for the bundled native hostCurrent symptom
The user's normal Chrome profile is already logged in to the required sites, and the extension/control toggle is enabled, but the current Codex task cannot obtain a callable browser-control interface or attach to the existing Chrome session. Re-selecting the model and retrying did not restore it.
A separate automation Chrome profile can be reached, but it is not the user's logged-in profile and is therefore not a valid workaround.
Sanitized app-log evidence
The app reports Browser Use as available:
At the same time, the current September 11 app log contains 24 occurrences of this route failure:
The raw log was not attached publicly because it contains conversation/session identifiers and local application paths. The excerpts above were sanitized before posting.
Network observations
cua_repllauncher /node_replprocesses do not containNODE_USE_ENV_PROXY,HTTP_PROXY,HTTPS_PROXY, orALL_PROXY.site_statusendpoint and received HTTP 403 in approximately 984 ms. This establishes basic transport reachability only; it does not establish authenticated policy-service success or rule out proxy inheritance as a contributing factor.This seems especially close to the September 11
26.903.71938reproduction already reported in this issue: local availability resolves to true, but no live browser-session route is available. Please advise whether this is a session-route/RPC regression in26.903.71938, a proxy-environment issue, or both, and whether there is a supported recovery that does not require editing generated plugin files or weakening browser safety controls.Pennliu commentedon Sep 13, 2026
I can reproduce the same symptom on macOS in the Codex desktop app using cua_repl.
Minimal diagnostic results
Chrome is discovered as an extension browser and can be selected successfully. No website navigation or tab claiming is needed to reproduce the failure.
The discovery/selection timings and the failing-call timings above come from separate diagnostic passes.
Additional observations
I have not established the underlying cause or verified a connection to code signing, proxy configuration, or CDP permissions. Exact component versions are not included in this comment because they have not yet been independently verified.
Is there a supported, privacy-preserving diagnostic that can identify which transport component is timing out?
tengfei-xy commentedon Sep 15, 2026
Additional macOS reproduction observed on 2026-09-15, with a newer desktop version and a lead concerning the prerequisite identity/policy request.
Environment
Observed behavior
browser.user.openTabs()andbrowser.nameSession(...)each fail after approximately 30 seconds withnodeRepl.fetch request failed.Prerequisite identity/policy request: diagnostic lead
Inspection of the bundled browser client shows that extension requests other than
getInfoawaitreadRequestHeaderEnabled()before sending the browser command. That prerequisite path includes an authenticated request to:and retrieval of the
codex_browser_use_agent_request_headerpolicy gate.The observed failure is reported by the browser runtime's authenticated-fetch bridge. Consequently, successful Chrome discovery does not establish that the failing tab/session commands reached the Chrome extension. A timeout at this prerequisite can present as a browser-control failure even before the browser command is sent.
This is not a confirmed root cause: the available error does not distinguish identity retrieval, policy initialization, authentication forwarding, or proxy/network handling. There is no evidence here establishing an extension DNR failure or a tab-initialization deadlock.
Network context and limits
The system and shell proxies point to a local loopback proxy. An independent, unauthenticated HTTP probe reached ChatGPT in under a second. That establishes transport reachability for that probe only; it does not establish that the browser tool's authenticated request succeeds or uses the same proxy path.
No effective workaround has been verified. #44140 describes a related request-header-policy/Statsig initialization path, but a shared root cause has not been established.
Could the browser runtime expose which prerequisite failed and preserve the underlying authenticated-fetch error? This would help distinguish identity/policy initialization failures from extension/native-host transport failures.
This comment excludes private URLs, page content, credentials, cookies, account/session identifiers, local usernames, and raw logs.
VidyFoo commentedon Sep 27, 2026
This adds a verified network-routing workaround for the macOS discovery/control split 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.