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

Open
#37,399 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
macos, rust
Domain
desktop, devtools

Research direction

Start with the browser.user.openTabs() and browser.user.claimTab() entry points and trace the packaged browser-control/native-messaging path on macOS. Reproduce the provided sequence, then verify that claimTab() either returns a controllable tab or rejects within a bounded timeout with an actionable error.

Written by the indexing model from the issue text.

Description

app browser bug tool-calls

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.

Dominant language
Rust
Stars
125k
Forks
19.5k
Avg merge
1m
Merged PRs (30d)
1k

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.