[macOS][26.825.51511] Closing Browser Use tabs recreates inert about:blank ghost tabs

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

Codex Desktop 26.825.51511 (bundle build 7377)

Embedded Codex Framework / Chromium: 151.0.7922.174

What subscription do you have?

Unknown — the exact subscription tier is not exposed in the local Codex Desktop diagnostic metadata I inspected. The app is signed in to a ChatGPT account.

What platform is your computer?

Darwin 27.0.0 arm64 arm

macOS 27.0 (26A5421a), Apple Silicon (arm64).

What issue are you seeing?

Closing agent-created in-app Browser / Browser Use tabs can remove the real page and play the normal close animation, but Codex then recreates the same tab identity as a visible, inert about:blank right-panel tab.

The replacement is rendered in the tab strip as a rounded “new tab”/globe pill. It has no usable page behind it, cannot be selected, and cannot be interacted with. Closing several Browser Use tabs can leave several of these ghost tabs next to each other.

This is not a website-specific failure: the local Codex Desktop lifecycle logs show that the original webview and guest are successfully destroyed, after which Codex itself recreates the same browser-use:<id> as a new right-panel webview with no URL.

User-visible behavior

• Click the close control on a visible in-app Browser tab.
• The expected close animation runs and the original page disappears.
• A replacement tab pill appears in the same tab strip.
• The replacement is blank and does not respond to clicks.
• Repeating the action can accumulate multiple inert tabs.
• Closing only the ghost entry does not reliably resolve the state; fully quitting and reopening Codex clears the stale UI/session binding.

Sanitized lifecycle evidence

The following events were recorded for the same redacted Browser Use tab identity. Private URLs, conversation IDs, session IDs, local paths, account details, and complete internal IDs have been removed.

2026-09-01T12:07:36Z IAB_LIFECYCLE renderer disposed browser sidebar webview
    browserTabId=browser-use:<redacted>

2026-09-01T12:07:36Z IAB_LIFECYCLE browser sidebar guest torn down
    browserTabId=browser-use:<redacted>

2026-09-01T12:07:36Z IAB_LIFECYCLE renderer removed browser sidebar webview
    browserTabId=browser-use:<redacted> tabType=closed

2026-09-01T12:07:36Z IAB_LIFECYCLE closed browser sidebar page
    browserTabId=browser-use:<redacted>

# Seconds later, the same browserTabId is recreated:

2026-09-01T12:07:42Z IAB_LIFECYCLE renderer created browser sidebar webview
    browserTabId=browser-use:<same-redacted-id>
    hostKind=right-panel
    initialUrl=about:blank

2026-09-01T12:07:42Z IAB_LIFECYCLE requested browser sidebar webview attachment
    browserTabId=browser-use:<same-redacted-id>
    hasPendingUrl=false
    hasUrl=false

The same close-then-recreate sequence occurred across multiple Browser Use tab IDs during the same session, rather than only once for one page.

After the ghost tabs appeared, later Browser Use activity also produced stale-context errors consistent with a page/session binding that no longer points to the original document:

Cannot find context with specified id
Node with given id does not belong to the document

A later Picture-in-Picture metadata event also reported tabID=undefined.

The persisted browser sidebar state registry contained multiple browser-use: page records after the close sequence. I am including that only as supporting state evidence, not claiming that persistence alone is the root cause.

What steps can reproduce the bug?

The issue occurred during a browser-heavy Codex task that created several agent-owned tabs. The following is the shortest observed reproduction; frequency may depend on the number of Browser Use tabs and whether the agent session still owns them.

1. Open Codex Desktop on macOS.
2. Run a Browser Use workflow that creates several in-app browser tabs.
3. Expose those tabs in the right-hand panel.
4. Close one of the visible Browser Use tabs using its normal close control.
5. Observe the close animation and removal of the original page.
6. Wait several seconds.
7. Observe a replacement tab pill appear. It is blank and cannot be selected or used.
8. Close additional Browser Use tabs; multiple inert pills may accumulate.

The logs show the behavior especially clearly when several agent-created tabs are closed in quick succession, but the UI should remain correct regardless of whether an agent session still has stale ownership.

What is the expected behavior?

• Closing a visible in-app Browser tab should permanently remove that tab entry, its webview, guest, renderer, and Browser Use/session ownership.
• A successfully closed browser-use: identity should not be recreated as a visible about:blank right-panel tab unless a new usable navigation was explicitly requested.
• If Browser Use still owns a tab when the user closes it, Codex should either release/reconcile the ownership cleanly or present a clear, usable state—not an inert tab.
• The tab strip should never contain entries that cannot be selected or individually dismissed.
• Subsequent Browser Use calls should rebind to a valid page/document context or return a clear lifecycle error without leaving stale UI.

Additional information

Likely failure boundary (inference, not confirmed root cause)

The logs suggest a lifecycle reconciliation race between manual tab close, Browser Use session ownership, and right-panel restoration:

1. The UI close path successfully disposes the renderer/webview and tears down the guest.
2. The tab is recorded as closed.
3. Another owner/state reconciliation path still treats the Browser Use tab identity as active or restorable.
4. Codex recreates that same identity in the visible right panel with initialUrl=about:blank, hasPendingUrl=false, and hasUrl=false.
5. The tab-strip entry survives without a valid page/context, producing the inert ghost tab.

A useful guard may be to treat a user close/tombstone as authoritative across Browser Use ownership and persisted sidebar restoration, or to reject/restage a right-panel attachment when both hasPendingUrl and hasUrl are false.

Impact

• Users cannot tell whether a page was closed or is still agent-owned.
• Ghost tabs accumulate and consume tab-strip space.
• Browser Use can subsequently target stale document contexts.
• The only reliable recovery observed is restarting Codex, which interrupts active work.
• The behavior is especially disruptive in workflows that legitimately create and close several temporary tabs.

Related but materially different reports

• #41653 — Windows right-pane ghost tabs that lose their close control. Similar user-visible stale-tab state, but this macOS report has a concrete close-then-recreate sequence for the same Browser Use ID and a new about:blank webview with no URL.
• #33133 — Browser tabs are disposed/closed and lose Browser Use ownership. Related lifecycle boundary, but that report focuses on tabs disappearing; here a successfully closed tab is recreated as a visible inert tab.
• #41891 — a closed in-app tab leaves media running. Related cleanup semantics, but not the blank-tab recreation described here.
• #40406 — agent tab lifecycle issue resolved as API misuse. Here the user manually closes visible tabs and the Desktop logs independently show the same ID recreated as right-panel / about:blank.

No private URLs, browsing content, account data, conversation IDs, session IDs, or full logs are included in this report.

Start by reproducing the close-then-recreate sequence from the Browser Use close control, using the lifecycle logs for the renderer, guest, and right-panel webview as the trace. Follow the Browser Use ownership and persisted sidebar restoration paths around the same browserTabId. Done means closing a tab removes its identity without recreating an inert about:blank entry, while later Browser Use activity retains a valid page context.