Bug Report

Summary

ensureTabAvailable() in server-context.selection.ts throws BrowserTabNotFoundError ("tab not found") due to a race condition where a newly opened tab's webSocketDebuggerUrl (wsUrl) hasn't populated in CDP's /json/list response yet. This is the dominant failure mode for browser tools on localhost agents.

Reproduction

Happens reliably on cold start and intermittently after Playwright errors. In a single day's logs, 14 of 18 browser tool failures were "tab not found" caused by this race.

Failure pattern 1 — Cold start (10 occurrences):

• Chrome starts at T+0
• ensureTabAvailable() calls listTabs() → empty (CDP not ready)
• Calls openTab("about:blank") → succeeds, returns BrowserTab with targetId
• Return value is discarded (line 41)
• Calls listTabs() again → may still be empty, or tab appears without wsUrl
• For local-managed profiles (supportsPerTabWs: true), candidates filtered by wsUrl → empty
• Throws BrowserTabNotFoundError

Failure pattern 2 — Post-Playwright-error (4 occurrences):

• Playwright click times out (8s) on a valid tab
• 23s later, next browser operation calls ensureTabAvailable()
• listTabs() returns tabs but wsUrl is stale/missing after the error
• supportsPerTabWs filter eliminates all candidates → "tab not found"

Root Cause

In extensions/browser/src/browser/server-context.selection.ts:36-78:

const tabs1 = await listTabs();
if (tabs1.length === 0) {
  await openTab("about:blank");  // ← Return value DISCARDED
}
const tabs = await listTabs();   // ← CDP may not reflect the tab yet
const candidates = capabilities.supportsPerTabWs
  ? tabs.filter((t) => Boolean(t.wsUrl))  // ← wsUrl may not be populated
  : tabs;
// candidates can be empty → throws BrowserTabNotFoundError

Two bugs compound:

1. openTab() returns a valid BrowserTab with targetId, but the result is thrown away
2. When supportsPerTabWs is true (all local-managed profiles), tabs without wsUrl are filtered out — but wsUrl from CDP /json/list can lag tab creation by hundreds of milliseconds

Proposed Fix

1. Capture openTab() return value and use it as a candidate when listTabs() doesn't reflect it
2. Add wsUrl discovery polling (up to 1s) when supportsPerTabWs filtering leaves candidates empty but tabs exist
3. Fall back to unfiltered tabs if polling exhausts — the persistent Playwright connection can still reach tabs by targetId

Related Issue

There is also a separate (lower-priority) issue where Playwright interaction actions (click, type, hover, drag, select) do not receive the dispatcher's AbortSignal, so when a transport timeout fires, the Playwright operation continues running orphaned against the live page. Only evaluate currently propagates req.signal.

Environment

• macOS, local-managed Chrome profile
• cdpPort: 18800
• Gateway running on port 18791
• Observed in daily agent workflows with multiple sequential browser tool calls

Log Evidence

2026-04-08T16:04:06.399Z  [tools] browser failed: tab not found
2026-04-08T16:04:06.399Z  [tools] browser failed: tab not found  (×10 at startup)
2026-04-08T17:08:28.422Z  [tools] browser failed: TimeoutError: locator.click: Timeout 8000ms exceeded.
2026-04-08T17:08:51.594Z  [tools] browser failed: tab not found  (23s after click timeout)