Sharing a reproducible browser-bridge issue from Codex CLI browser-auth workflows on current Chrome builds.
What I saw:
- The protected Chrome tab stayed visible and logged in.
- getUserTabs() still returned the tab, and claimUserTab(tabId) could succeed.
- In the same session/turn, getTabs() could be empty or attach could fail with a “Tab … is not part of browser session …” error.
- That made the low-level path look blocked even though the same profile and tab were still alive.
- In a fresh turn, the bundled high-level browser-client runtime could sometimes reclaim the same profile/tab and continue.
A second nuance: on LinkedIn Page admin, the outer shell looked navigation-only, but the real composer and submit control lived inside iframe[src=“/preload/”]. Once the tab was reclaimed through the higher-level runtime, posting worked.
What would help:
- a documented health signal for which layer is authoritative when getUserTabs() and attach/getTabs disagree
- a supported recovery path for session ownership that does not require restarting Chrome
- clearer diagnostics when the interactive surface is inside an iframe and the outer shell looks unwritable
If useful, I can turn this into a tighter repro matrix with the exact request order and observed outcomes.