In-app browser cannot claim explicitly attached tab; openTabs() returns empty

What version of the Codex App are you using (From “About Codex” dialog)?

The exact Codex app version was not available from the bundled CLI path. The browser plugin attachment referenced build 26.810.52044, while the locally callable bundled browser runtime was 26.727.51351.

What subscription do you have?

Not included in this public report.

What platform is your computer?

macOS 14.5, Apple Silicon (arm64)

What issue are you seeing?

The Codex in-app browser is visibly open, signed in, and manually usable, but Codex cannot claim or control the exact tab attached to the prompt.

The prompt contains a valid explicit tab mention in this form:

plugin://browser@openai-bundled?mention=tab-v1&browserId=<session>&tabId=<tab>&title=<title>&url=<url>

The browser runtime discovers the matching iab backend by metadata.codexSessionId, but both calls return empty arrays:

await browser.user.openTabs() // []
await browser.tabs.list()     // []

The Codex app's ambient browser context still reports one open tab at the expected URL, and the user can see and interact with that tab manually.

Earlier in the same thread, the automation backend exposed a different AWS tab with a signed-out cookie session even though the visible in-app tab was signed in. Navigating or opening a fresh automation tab also used the signed-out cookie session. This indicates that the visible browser pane, tab-claim registry, and automation session can become desynchronized.

The failure is not site-specific. AWS was simply the site where the mismatch was consistently observable.

What steps can reproduce the bug?

1. Open the Codex in-app browser.
2. Navigate to a site and sign in.
3. Attach that exact browser tab to the prompt so the message contains a mention=tab-v1 browser link.
4. Ask Codex to control the attached tab.
5. Resolve the iab browser whose metadata.codexSessionId matches the browser ID from the attachment.
6. Call browser.user.openTabs().
7. Observe that it returns [], so the explicitly attached tab cannot be claimed.
8. Call browser.tabs.list().
9. Observe that it also returns [], while the Codex app visibly shows the tab.

Restarting/reopening the browser pane and attaching the tab again did not resolve the mismatch.

What is the expected behavior?

An explicitly attached tab-v1 in-app browser tab should appear in browser.user.openTabs() with the matching provider tab ID, title, and URL, so Codex can pass that object to browser.user.claimTab(tab).

The automation session should use the same tab and cookie session that the user sees in the in-app browser.

Additional information

Potential version-skew signal:

• Attached browser skill link: 26.810.52044
• Callable cached browser runtime: 26.727.51351

No private URLs, account identifiers, browser/session IDs, or logs are included in this public report.

Start by tracing how the explicit tab-v1 mention is resolved to the iab browser using metadata.codexSessionId, then compare the attached browser skill version with the callable cached runtime. Reproduce the mismatch with browser.user.openTabs() and browser.tabs.list(); done means the attached tab appears with its provider ID, title, and URL and uses the visible tab's session when claimed.