Codex Chrome plugin: `Browser is not available` after `openTabs()` breaks `claimTab` / `tabs.get` / controlled tab workflows

Summary

The Codex Desktop Chrome plugin (chrome@openai-bundled) intermittently loses its extension browser handle after lightweight tab discovery succeeds. browser.user.openTabs() can list live Chrome tabs, but subsequent tab-control operations such as browser.user.claimTab(...), browser.tabs.get(...), or controlling a newly-created tab frequently fail with:

Browser is not available: <browser-id>

This makes Chrome-backed workflows unreliable for tasks that depend on the user's existing Chrome session.

Environment

• Product: Codex Desktop
• Plugin: chrome@openai-bundled
• Local plugin version: 26.623.141536
• Extension ID from local plugin metadata: hehggadaopoacecdllhhajmbjkdcmajg
• Platform observed: macOS / Codex desktop
• Date observed: 2026-07-09

What worked

• Browser setup completed using the packaged scripts/browser-client.mjs flow.
• await browser.documentation() returned normally.
• await browser.user.openTabs() repeatedly returned live Chrome tabs, including the target ChatGPT tab.
• At times, creating a new controlled tab and navigating to the target ChatGPT conversation URL also succeeded.

What failed

After successful lightweight discovery, direct tab control frequently failed:

await browser.user.openTabs(); // succeeds and returns target tab(s)
await browser.user.claimTab(targetTabInfo); // often fails
// Error: Browser is not available: <browser-id>

Similar failures occurred with:

await browser.tabs.get(tabId);
await browser.tabs.new(); // sometimes succeeds, but later page interaction fails

A fresh agent.browsers.get("extension") may temporarily allow another openTabs() call, but the next tab-control call can invalidate the handle again.

Impact

A user requested a batch workflow in an existing signed-in ChatGPT conversation:

1. Reuse a long prompt template from the conversation.
2. Replace only the main character / 主角色为：{{...}} slot for each name.
3. Submit each prompt.
4. Save each generated image to a local folder.

This should be a straightforward Chrome plugin task because it depends on existing Chrome login state. The workflow became unusable because the plugin could see the tabs but could not reliably claim/control them.

Expected behavior

If openTabs() returns a tab from the selected extension-backed Chrome browser, claimTab() or tabs.get() should reliably return a controllable Tab, or fail with a specific recoverable reason. The browser handle should not become unavailable immediately after successful discovery.

Actual behavior

The plugin repeatedly returned:

Browser is not available: <browser-id>

after successful openTabs() calls, forcing repeated browser reinitialization without a stable recovery path.

Suggested diagnostics

• Check whether the extension backend/browser ID is being invalidated between discovery and session-bound tab-control commands.
• Check session/turn metadata handling around claimUserTab, getTabs, createTab, and attach calls.
• Consider making claimTab() refresh/reselect the extension backend automatically when the browser handle disappears after a successful openTabs() result.
• Return a more actionable error when the backend has closed or the extension/native host session has rotated.

Notes

This was observed while using the documented Chrome plugin flow, not external Playwright, AppleScript, or Computer Use.