[macOS][Chrome] openTabs succeeds but claimTab hangs until JS kernel reset

Disclosure: This issue is being submitted by the user's Codex assistant, at the user's explicit request and on their behalf. No browsing history, page content, account data, session transcript, or logs are attached.

Environment

• Codex / ChatGPT desktop app: 26.803.41515
• Bundled Codex CLI: 0.147.0-alpha.6.5
• Bundled Chrome plugin: 26.803.41515
• Google Chrome: 151.0.7922.108
• ChatGPT Chrome extension: 1.2.27236.6274
• Extension ID: hehggadaopoacecdllhhajmbjkdcmajg
• Platform (uname -mprs): Darwin 25.5.0 arm64 arm
• macOS: 26.5.1 (build 25F80)
• Chrome profile: Default
• Subscription: signed-in ChatGPT account; exact plan was not checked

What issue are you seeing?

The official Chrome browser-control path can reliably discover existing Chrome tabs with browser.user.openTabs(), but browser.user.claimTab(tabInfo) never returns when passed the exact tab object returned by openTabs().

The call remains pending until the outer Node/browser-control execution times out and resets the JavaScript kernel:

js execution timed out; kernel reset, rerun your request

This prevents the tab from becoming controllable, so screenshot and DOM operations cannot start reliably.

This is not a basic extension-installation or tab-discovery failure: the extension/native-host checks pass and openTabs() returns the live tabs.

What steps can reproduce the bug?

1. On macOS, start the current Codex/ChatGPT desktop app.
2. Enable the official Chrome plugin and extension in Chrome's Default profile.
3. Open a normal HTTPS page in Chrome.
4. Initialize the official packaged browser client.
5. Run:

const tabs = await browser.user.openTabs(); // succeeds
const tab = await browser.user.claimTab(tabs[0]); // never returns

1. Wait for the outer execution timeout.
2. The JS kernel is reset instead of claimTab() returning a tab or a bounded error.

The same failure remained after retrying from a new Codex task and a fresh Chrome Default-profile window.

What is the expected behavior?

After openTabs() returns a live tab, claimTab() should promptly return a controllable tab. If the claim cannot succeed, it should reject within a bounded timeout with an actionable error identifying the failing layer.

Troubleshooting already completed

All four packaged Chrome diagnostics passed:

• Chrome running
• extension installed and enabled in Default
• native host manifest present
• expected native-messaging origins and manifest path valid

Also tested:

• reinstalled the Chrome plugin
• restarted Chrome
• restarted Codex/ChatGPT desktop
• performed a full macOS restart
• reproduced in a new Codex task
• opened a fresh Default-profile Chrome window using the packaged troubleshooting script
• cleared a possible stale local browser-control process and retried

This Mac uses a local system proxy. Direct access to ab.chatgpt.com timed out, while a proxy-aware Node test reached the endpoint promptly (HTTP 403). Running the browser-control client in that proxy-aware environment still left claimTab() hanging, so the claim failure is not explained solely by ambient endpoint reachability.

Related issues and distinguishing behavior

• #31706: openTabs() succeeds, but claimTab() fails immediately with Browser is not available. Here, claimTab() hangs until kernel reset.
• #34472: stale-session lock and explicit lock symptoms. No equivalent stale-session error was returned here.
• #36278: claimTab() succeeds and the later DOM read hangs. Here, the hang occurs during claimTab() itself.

Additional information

No external Playwright/CDP workaround was used to control Chrome. No browser databases, cookies, saved passwords, history, page contents, or authenticated account data were read or included in this report.