Repository navigation
[macOS, 26.915.31945] Chrome discovery succeeds but tab enumeration fails after ~30s with nodeRepl.fetch request failed #46609
Description
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT desktop / Codex-integrated app 26.915.31945, build 9922, read from the installed application's Info.plist. Availability of a newer release has not been verified.
What subscription do you have?
Not included in this diagnostic report.
What platform is your computer?
- macOS 15.7.8, Apple Silicon / arm64.
- Google Chrome 153.0.8010.48.
- Official ChatGPT Chrome extension 1.26.901.11451, installed and enabled. The Chrome Web Store showed the same version when checked.
- Reproduction date: September 19, 2026.
What issue are you seeing?
Chrome extension discovery succeeds and the extension side panel loads normally, but enumerating Chrome tabs through the official Computer Use API consistently fails after approximately 30 seconds:
nodeRepl.fetch request failed
The failure occurs while requesting the browser's tab list, without selecting a website. It is not evidence that a particular website is blocked, and we have not established that every individual tab would fail independently.
| Operation | Observed result |
|---|---|
cua.listBrowsers() |
Succeeds; returns Chrome with type: "extension" |
cua.listTabs({browser: currentChromeId}) |
Fails after approximately 30.09–30.24 seconds in repeated tests |
Same enumeration with outer tool timeout_ms: 60000 |
Still fails around 30 seconds |
cua.getState() |
Returns the native app inventory, but browsers: [] and a browser fetch error |
| Native Computer Use on Chrome settings, extension management and the official extension-store page | Reading UI state and clicking succeed |
| ChatGPT extension side panel | Loads normally, including after extension reconnection |
Native UI success is a separate observation; extension tab enumeration has not recovered.
What steps can reproduce the bug?
In an affected desktop task, with Chrome running and the official extension enabled:
- Use the supported
cua_repltool:
await cua.listBrowsers();- Select the ID returned by that live call for
family: "chrome",type: "extension". - In the same runtime, call:
await cua.listTabs({browser: currentChromeId});currentChromeId above is a placeholder for the discovered ID. IDs were rediscovered after runtime resets and extension reconnection; stale IDs were not reused.
- Observe
nodeRepl.fetch request failedaround 30 seconds later, even with a 60-second outer tool timeout. - A newly created diagnostic task reproduces the same discovery-success/enumeration-failure split.
This is repeatable on the affected machine, not a verified clean-install reproducer.
What is the expected behavior?
Chrome tab enumeration should succeed after discovery, or return an actionable error identifying the failed dependency and underlying transport cause. The generic fetch error does not indicate whether the failure involves identity/policy initialization, extension RPC transport, or another component.
Additional information
Recovery attempts and results
- User restarted Chrome: no recovery.
- Desktop logs show a new application process before the fresh-task reproduction: no recovery in subsequent tests.
- Created a fresh diagnostic task: still fails.
- Reset the CUA JavaScript runtime, rediscovered Chrome, and retried: still fails.
- Disabled and re-enabled only the ChatGPT Chrome extension, reopened its side panel, and rediscovered the new browser ID: side panel works; enumeration still fails.
- Before reconnection, the extension worker console showed
Unchecked runtime.lastError: Cannot create item with duplicate id ask-chatgpt. After reconnection, the console showed no messages, but enumeration still failed. - Checked extension settings: enabled, site access already set to “On all sites,” native-app communication permission present. No permissions were broadened.
- Requested an empty in-app browser panel through the app's supported panel tool and navigated back to this diagnostic task. The panel request was initially queued; actual panel creation was not verified. Chrome enumeration still failed afterward.
Related local log evidence — causality unconfirmed
The desktop log also records IAB route errors for the same diagnostic task:
[browser-use-iab-api] iab backend info request failed
conversationId=<diagnostic-task> request=getInfo
errorMessage="No ChatGPT browser route is available for browser session <diagnostic-task>"
Earlier entries show session-route capture/backend startup, and at least one getInfo completion. The IAB warning therefore must not be treated as proof of the Chrome failure's cause.
An earlier attempt in the original task also reported:
Unable to load browser request-header policy. Retry the browser command.
That specific policy error was not reproduced in the fresh diagnostic task. We have not captured the failing authenticated request's URL or lower-level error code.
Network context
A local HTTP/HTTPS/SOCKS system proxy is configured. Unauthenticated terminal HEAD probes to the roots of chatgpt.com and ab.chatgpt.com returned HTTP 403 in under a second. These probes establish only that the terminal received responses; they do not validate authenticated identity/policy requests or the CUA transport. Application-service TCP connections to the local proxy were observed. No controlled TUN/proxy-path comparison has been performed, so proxy handling remains an unconfirmed hypothesis.
No browser cache/cookies were deleted, no extension was reinstalled in this investigation, and no bundled runtime, installed skill, identity/policy logic or security setting was patched. No community workaround was applied.
Related reports
- [macOS, 26.901.51231] Chrome is discovered, but browser-control calls fail with nodeRepl.fetch request failed #43787: similar macOS + Chrome discovery/control split on an earlier version.
- [macOS, 26.903.61454, Edge] Extension discovery succeeds but tab enumeration times out, including in a fresh task #44390: macOS extension enumeration fails around 30 seconds, including a fresh task.
- [Windows][Desktop] Browser tab RPCs block on unbounded request-header identity lookup #45014: another reporter located an identity/request-header dependency; that cause has not been demonstrated on this machine.
- # In-app browser renders pages but agent control times out #46137: similar IAB route warning, potentially a separate issue.
This report adds a reproduction on 26.915.31945 / build 9922 and the recovery results above. Could maintainers advise on a supported diagnostic for the underlying authenticated_fetch failure and whether a supported fix exists? Please distinguish the Chrome tab RPC failure from the accompanying IAB routing warning.
This report omits account identifiers, private browsing content, local usernames/paths, task and extension-instance IDs, credentials, screenshots and raw log files.
Activity
github-actions commentedon Sep 19, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
cntsiny commentedon Sep 21, 2026
Additional affected macOS installation. I have submitted in-app feedback; please correlate this report with feedback ID
01a0c1d6-8ef8-7071-979d-2859cd437fd1.Recorded environment
Local diagnostics collected on September 21, 2026 (versions were not resampled at the latest failed attempt):
Current symptoms
nodeRepl.fetch request failedbefore a controlled test page could be established.Recovery already attempted
Application restarts, control-session reset, lease release, and a fresh task did not restore Chrome control. A controlled normal quit/relaunch was independently checked using local process snapshots: selected application-bundle processes went 519 → 0 → 21. The 23 post-relaunch snapshots over 11 minutes remained at 21, with the same main app-server and eight descendants. Normal quit was sufficient; no additional termination signals, configuration edits, or Chrome-profile edits were recorded by the recovery procedure. Chrome still failed afterward.
This is symptom overlap with this issue, not confirmation of an identical root cause. No reliable failure duration or underlying error code/cause has been captured for this installation. Earlier static native-host and proxy checks did not validate the failed control runtime's effective environment or route; proxy handling is not ruled out.
Could maintainers use the feedback ID to identify the first failing stage, whether the Chrome control request reaches the extension, and a supported diagnostic or fix? No raw logs, screenshots, conversation contents, personal-tab contents, or business data are attached to this public comment.
cntsiny commentedon Sep 22, 2026
Follow-up: mandatory
nameSessionfails before any tab requestFollowing up on my earlier comment, with the same in-app feedback ID
01a0c1d6-8ef8-7071-979d-2859cd437fd1. This ID is for case continuity; the older submitted diagnostic bundle should not be assumed to contain the newer local trace described below.Recorded environment: September 21 diagnostics showed macOS 26.5.2 / Apple Silicon, ChatGPT desktop / Codex-integrated app 26.915.31945 (build 9922), Chrome 153.0.8010.52, and official ChatGPT Chrome extension 1.26.901.11451. These app/browser/extension versions were not freshly resampled during the later trace. The unified-computer-use implementation inspected during the September 22 trace was 26.915.31945.
New staged evidence from September 22:
browser.nameSession(...)nodeRepl.fetch request failed; the post-await success marker did not executetabs.new(), navigation and page operationsThe Chrome-specific documentation returned by the selected backend on this installation requires
browser.nameSession(...)immediately after setup and before opening or claiming tabs for every Chrome task. This is a finding about the currently inspected backend guidance, not a claim about all versions. A later contract-only check read that guidance without repeating NameSession or creating a page. We did not omit the required command, ignore its failure, or modify the installed runtime to bypass it.Remaining diagnostic gap: the inspected records expose no NameSession request ID, dispatch timestamp, provider/extension receipt, ACK/NACK, or response correlation. We therefore cannot distinguish a pre-send failure from receipt without a reply or a lower-level rejection whose cause is not surfaced. This does not prove that the extension received the request, that tab creation itself fails, or that all Chrome commands share one cause.
Could maintainers provide a supported fix or command-level diagnostic method that identifies the first failing transport boundary and underlying error? We are not requesting an ownership or security bypass.
No raw logs, screenshots, conversation contents, private repository links, local paths, personal-tab information, credentials or business data are attached to this addendum.
VidyFoo commentedon Sep 27, 2026
This closely matches the macOS discovery-success / ~30-second enumeration-failure pattern reported 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.jxfzzyz commentedon Oct 7, 2026
Additional reproduction and narrower diagnostics on 2026-10-08, with desktop 26.1002.51308 (build 13417), macOS 26.4 (25E246), arm64, and bundled @oai/cua 0.2.6.
This adds connection-path and cancellation-bridge evidence to the discovery/enumeration split already reported here. It does not establish that the accompanying IAB routing warning causes Chrome's failure.
Reproduction and observed results
Using the documented
mcp__cua_repl.jsAPI:await cua.listBrowsers();succeeded in about 0.24 s and returned Chrome as an extension-backed browser.await cua.listTabs({browser: currentChromeId});repeatedly failed after 30.19–30.30 s, even with a 40 s outer tool limit, with:cua.getState()calls timed out and reset the kernel. An IAB create-tab call also timed out, but later enumeration showed that the requested tab had actually been created. These earlier symptoms may involve additional failure paths; they should not all be attributed to Chrome.Verified network-path observations
node_replprocess had direct external TCP connections stuck in SYN_SENT, including destinations returned by the system resolver forchatgpt.com. These connections were not to the configured local proxy.https://chatgpt.com/backend-api/aura/identitywithout explicitly specifying the proxy timed out after 15 s, with no completed TCP/TLS connection and HTTP status 000.No credentials were used in these terminal probes. No authenticated CUA request was replayed outside the supported tool.
Source-level cancellation and failure-propagation observations
In the installed generated
privileged-node-repl.js,authenticatedFetch(input, init)constructs a Request, then serializes method, URL, headers, and optional body into anauthenticated_fetchmessage. The pending response promise has no abort listener, and the request's cancellation signal is not forwarded in that message.The bundled browser service supplies a 10 s AbortSignal timeout for its identity fetch, but the bridge above does not preserve cancellation while waiting for the supervisor's response. Please verify the intended cancellation contract and whether this explains the longer wait. This is a source-level observation, not a separately executed cancellation regression test.
The installed
get_state.js/get_browsers.jsalso wait for all requested browser inventories. A stalled browser dependency therefore delays the aggregate state read even when the IAB backend can respond promptly.Diagnosis limits and request
The observations establish an unusable direct-network path alongside a usable explicitly proxied path, and an apparent cancellation propagation gap. We have not captured the exact failed authenticated request URL, verified authenticated recovery after a network-path change, or established which internal configuration/client causes those connections to bypass the macOS system proxy. They do not prove a Chrome extension defect.
Please investigate the supported proxy behavior of CUA's authenticated-fetch transport, propagation of cancellation/deadlines, and actionable reporting/isolation of failed browser dependencies.
No desktop/browser restarts, permission changes, proxy/DNS/configuration changes, bundled-code changes, or project/task-state changes were made. This comment excludes local usernames and paths, IP addresses, proxy addresses/ports, process IDs, task IDs, browser/extension-instance IDs, credentials, browsing history, project data, and full logs.