Browser Use loses active pane binding after chat/browser detach

Additional Windows repro from Codex Desktop 26.429.3425.0.

Environment:

• Windows 11 Home Single Language, version 10.0.26200
• PowerShell 5.1.26100.8115
• Browser Use plugin: openai-bundled/browser-use/0.1.0-alpha1
• In-app browser visible to user at http://localhost:3000/onboard#pricing

Observed:

• Browser Use iab bootstrap succeeds enough to call agent.browser.tabs.selected().
• The selected tab returned by Browser Use is not the visible local app page.
• Browser Use reports:
• title: This site can't be reached
• url: data:text/html;charset=utf-8,...
• Decoding the data: URL shows a Chromium error page for failed URL http://localhost:3000/onboard#pricing with ERR_TOO_MANY_REDIRECTS.
• A separate browser control surface can navigate to http://localhost:3000/, inspect the page DOM, and click the Pricing nav link, ending at http://localhost:3000/#pricing.
• That suggests the local app and browser rendering are not the blocker; Browser Use appears to bind to the wrong/derived in-app browser state.

Expected:

• Browser Use should bind to the visible in-app browser pane/tab for the active thread.
• If the pane/tab is detached, stale, or represented by an internal generated error document, Browser Use should expose a clear recovery action.
• The error should distinguish "no active pane exists" from "pane exists but Browser Use selected a generated error/data URL surface".

This seems related to the active pane binding loss described here, but it is not identical: in this repro, selected() returns a tab, just not the visible app tab.

I’m seeing a closely related variant on macOS Codex Desktop.

When I ask an agent to use @Browser, then open that agent/chat in a new window, the Browser tab being used by the agent remains visible in the original Codex window but is not visible in the new window. So the agent/browser state appears to stay bound to the original window instead of following the detached/new window.

This makes it look like the new window has no active Browser tab even though the Browser session exists and is visible elsewhere.

This seems related to the active pane/window binding problem described here, but the user-visible symptom is specifically “Browser tab appears in original window, not the new window.”

I hit a closely related failure today with a more concrete trigger: a third-party popup/callback flow from the Codex in-app browser.

Environment

• Codex Desktop: 26.513.31313 / build 2867
• Platform: macOS arm64 (Darwin 25.3.0)
• Browser backend: Codex In-app Browser (iab)
• Browser plugin path used by the skill: openai-bundled/browser/0.1.0-alpha2/scripts/browser-client.mjs

Trigger / reproduction pattern

1. Open an ecommerce cart page in the Codex in-app browser.
2. Open the site's saved shipping-address popup from the cart page.
3. Select a saved address.
4. Click the popup action equivalent to "use this address for this order".
5. Click the confirmation button in the popup.

Expected behavior

The popup should close and the original cart page should remain the active visible in-app browser tab. Browser automation should still be able to call:

await browser.tabs.list()
await browser.tabs.selected()
await browser.tabs.new()
await tab.goto(...)

Actual behavior

After confirming the popup:

• The visible in-app browser panel shows about:blank.
• The browser visibility capability still works: visibility.set(false) / visibility.set(true) both return successfully.
• The browser object can still be acquired with await agent.browsers.get('iab').
• But every tab operation fails with:

No active Codex browser pane available

Observed failures:

browser.tabs.list() -> No active Codex browser pane available
browser.tabs.new() -> No active Codex browser pane available
browser.tabs.selected() -> No active Codex browser pane available

Trying to hide/show the browser panel did not recreate a usable active pane:

const vis = await browser.capabilities.get('visibility')
await vis.set(false)
await vis.set(true)
await browser.tabs.list() // still fails
await browser.tabs.new()  // still fails

Why this may be the same class of bug

This looks like an active-pane binding loss, but the trigger was not a manual detach/min-window action. It was a normal web popup/callback close flow. The UI still shows an in-app browser surface, but the automation layer no longer has an active pane to bind to, and it cannot recover by opening a new tab or navigating the current blank page.

Impact

Any workflow that uses a real web popup/callback flow can leave the in-app browser permanently stuck for the current thread/session. The practical recovery was to restart/recreate the in-app browser pane or the Codex app; API-level recovery attempts did not work.

I intentionally omitted site account, address, and other user-specific data from this report.

Additional current macOS reproduction on Codex Desktop 26.707.31123 (build 5042). This looks like the same active-pane binding/state synchronization bug, with an especially clear disagreement between the visible UI context and the Browser runtime.

Environment

• Codex Desktop / ChatGPT app: 26.707.31123 (build 5042)
• Bundled Browser plugin: 26.707.31123
• Bundled Codex CLI: 0.144.0-alpha.4
• macOS: 26.5.2 (build 25F84), arm64
• Browser backend: Codex In-app Browser (iab)
• Test page: a non-sensitive localhost app at http://localhost:8000/__dev-workbench/
• The localhost service independently returned HTTP 200 throughout the reproduction.

Reproduction

1. Open the in-app Browser panel with the localhost page loaded.
2. Confirm the Codex conversation context reports:

• the in-app browser is open,
• one tab exists,
• current URL is http://localhost:8000/__dev-workbench/.

1. Bootstrap the bundled Browser plugin with setupBrowserRuntime({ globals: globalThis }).
2. Select the IAB backend with await agent.browsers.get("iab").
3. Inspect:

• await browser.tabs.list()
• await browser.tabs.selected()
• await browser.user.openTabs()
• await (await browser.capabilities.get("visibility")).get()

1. Attempt recovery:

• create a new tab,
• navigate it to the same localhost URL,
• call visibility.set(true),
• inspect the four state signals again.

Actual behavior

Even while the Codex UI/context says the browser panel is open with one tab, the Browser runtime reports:

{
  "tabs": [],
  "selected": null,
  "openTabs": [],
  "visible": false
}

A recovery attempt partially works:

• tabs.new() returns a tab (observed id 3).
• tab.goto("http://localhost:8000/__dev-workbench/") succeeds.
• The page title is 开发工作台.
• A DOM snapshot returns the expected page content.

But presentation/binding does not recover:

• visibility.set(true) returns without an error.
• visibility.get() still returns false.
• The transient tab subsequently disappears from tabs.list().
• selected() and user.openTabs() return empty again.

After manually reopening/toggling the Browser panel, the Codex UI context again reports one visible tab at the localhost URL, while the Browser runtime still returns the empty/false state above.

Expected behavior

• The visible in-app Browser pane and its selected tab should be registered with the active thread's Browser runtime.
• If the UI reports one current tab, tabs.list(), selected(), and user.openTabs() should reflect it.
• After visibility.set(true) succeeds, visibility.get() should return true, or the setter should report that presentation failed.
• A successfully created and navigated IAB tab should not be silently discarded because the visible pane binding is stale.
• The API should expose a recovery action or a diagnostic state that distinguishes “no pane exists” from “pane exists in UI but is not bound to this thread/runtime.”

Related reports

• #22678 covers hidden/visible session divergence and includes a similar “context says open, bridge cannot attach” variant.
• #23962 covers visibility.set(true) succeeding while visibility.get() remains false.
• This reproduction adds a current macOS regression where both symptoms occur together and the visible UI context explicitly disagrees with all Browser runtime tab/visibility signals.

No credentials, cookies, page contents beyond the localhost title, or private session data are included.

Additional Windows reproduction on Codex Desktop 26.707.3748.0, with bundled Browser plugin 26.707.31428.

This appears to be the same active-pane binding/state synchronization failure, with a concrete concurrent cross-thread trigger and matching IAB_LIFECYCLE evidence.

Environment

• Windows 11 x64
• Codex Desktop: 26.707.3748.0
• Bundled Browser plugin: 26.707.31428
• Browser backend: Codex In-app Browser (iab)

Trigger / reproduction

1. Several existing Codex threads were resumed at nearly the same time.
2. Multiple threads in the same desktop window attempted to use IAB for different workflows.
3. The right-side Browser pane remained visible and showed the expected URL, but the page became blank.
4. In the active thread, browser.tabs.list() and browser.user.openTabs() returned empty arrays, and browser.tabs.selected() returned null.
5. browser.tabs.new() repeatedly failed after waiting for the webview attachment.
6. Resetting the JS runtime, toggling Browser visibility, switching away from the thread and back, and closing/reopening the visible tab did not restore the binding.

Relevant local log signatures

• No ChatGPT browser route is available for browser session <thread-id>
• rejected browser sidebar webview attachment ... hasMissingRestoreIntent=true
• browser use open wait rejected ... Timed out waiting for the Browser webview to attach for this browser-use page
• Before the failure, the logs contain rapid rebound browser sidebar window and owner/route synchronization events across several conversation IDs.
• In at least one sequence, the activeConversationId differed from the conversationId requesting the Browser route.
• After the timeout, the renderer disposed and removed the browser sidebar webview.

The target page happened to be a webmail site, but the failure occurred in Codex route/webview attachment and also affected about:blank/createTab, so it does not appear site-specific.

Hypothesis

There may be a race in shared right-panel webview ownership / restore-intent handling when multiple threads activate Browser Use concurrently or ownership changes quickly. Per-thread browser state exists, but the shared visible host can lose the route needed to restore the requesting thread.

Expected behavior

• Concurrent IAB requests should be serialized or rejected without corrupting the visible pane binding.
• Switching threads should reliably restore each thread's saved browser state.
• A visible pane should be reattachable to the active thread.
• If recovery is impossible, Codex should expose a clear reset/recreate action instead of leaving a blank pane.

Current workaround

• Fully quit and restart Codex.
• Allow only one thread at a time to actively use IAB.
• Avoid concurrently broadcasting work that may start Browser Use.

This confirms the issue still reproduces on a current Windows 26.707 build and adds a concurrency-related trigger plus the hasMissingRestoreIntent log signal.

I can reproduce a closely related user-facing manifestation on Windows 10, build 19045, with ChatGPT Codex Desktop App Version 26.707.31428

Reproduction:

1. Open a working in-app browser tab.
2. Make the browser tab inactive.
3. Reactivate it.
4. The browser pane is blank and does not display the existing page.
5. Refreshing the tab does not recover it.
6. Asking the Codex model to show or rerender the browser tab restores the display.

During an agent-side diagnostic:

• The in-app browser backend remained available.
• A controllable browser tab existed.
• A request to make the browser visible completed without an error.
• The visibility capability still reported false.
• Creating another controlled tab did not make the pane visible.

This appears related to the pane-binding/detachment problem reported here, but from the opposite direction: the backend still recognizes and controls the tab, while the Codex UI does not present/render the pane.

This may also share the sidebar webview lifecycle or rehydration cause discussed in #21824.

Additional Windows reproduction and code-level comparison for the active-pane / shared-right-panel lifecycle failure.

Environment

• Windows 10 x64
• registered Codex Desktop package: 26.707.6957.0
• locally staged official update also inspected: 26.707.8479.0
• backend: Codex in-app Browser (iab)

Observed failure

After cross-thread Browser use and rapid task switching, a tab could remain alive while the visible right-panel host was blank or bound to another task. In affected states, guest DOM/navigation evidence remained healthy, but the whole Codex window did not contain the guest pixels in the expected right panel. This is consistent with the UI/runtime disagreement already documented in this issue.

Version comparison

The official ASARs were inspected read-only:

• 26.707.6957.0: A728370E715DFA2E8AAA01D1E67C4C27087608CD8FA527D1B3D46CED78A3A8EB
• 26.707.8479.0: 8DDC04D44985CA64D59097A76E5871C1010EEB94D7305FD61C5B3F111D452DFF

Two relevant packed assets are byte-identical in both packages:

• app-main-CnX2qEsn.js: 2B30220B986AF70B4D24386A54FF4CCB6D21162615FC4723B5CFDF4FDB68BC49
• browser-sidebar-manager-BKDVnejf.js: F284A94D9ECEDA6A49E00EA9C0F2F81C3CD7044E45E5154C9D49FB02BB9201CF

Both main bundles also retain the same two agent-origin-only handoff branches. The newer staged package does not contain all-origin handoff preservation or bounded keyed registration recovery. This shows that the relevant lifecycle fix is not present in the newer package; it does not claim that every IAB crash has this single cause.

Fix design validated in a self-owned test image

• consume pending capability/visibility intents in both claim paths;
• preserve handoff tabs for both user and agent origins;
• defer background visibility until the owning task is authoritative;
• use stable BrowserUse persistence identity;
• use bounded keyed registration recovery for missing bridge/session, rejection, release, and target conflict paths;
• detect a two-frame persistent 0x0 visible host, pulse it non-destructively, then rebuild only that exact host once if needed;
• abort recovery on owner/visibility changes and enforce in-flight/cooldown/loop guards.

Validation included synthetic lifecycle/race cases, ASAR round-trip checks, injected rollback failures, guest and whole-window pixel checks, and task A -> B -> A reattachment.

Sanitized report, reproduction checklist, version evidence, and fix design:

https://github.com/changshengjiuan13-eng/codex-desktop-iab-null-tail-recovery

No official Desktop binaries, Browser profile, authentication material, or private rollout data are included.