[macOS, 26.915.31945] Chrome discovery succeeds but tab enumeration fails after ~30s with nodeRepl.fetch request failed

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:

1. Use the supported cua_repl tool:

await cua.listBrowsers();

2. Select the ID returned by that live call for family: "chrome", type: "extension".
3. 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.

4. Observe nodeRepl.fetch request failed around 30 seconds later, even with a 60-second outer tool timeout.
5. 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

• #43787: similar macOS + Chrome discovery/control split on an earlier version.
• #44390: macOS extension enumeration fails around 30 seconds, including a fresh task.
• #45014: another reporter located an identity/request-header dependency; that cause has not been demonstrated on this machine.
• #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.

Start with the supported cua_repl entry points: reproduce cua.listBrowsers(), cua.listTabs(), and cua.getState() using a freshly discovered browser ID. Compare the roughly 30-second failure with the desktop logs around authenticated_fetch and browser-use-iab-api, keeping the IAB warning separate unless evidence connects them. Done means identifying the failing dependency and transport cause, or returning an actionable error instead of the generic fetch failure.