fix: stabilize tab IDs to prevent index drift when tabs are closed externally

[yangyaofei]

Summary

Stabilize tab identifiers when connecting to an existing browser via CDP (--cdp). Currently tab list, tab switch, and tab close use volatile array indices that shift when tabs are opened or closed by the user (or any external actor), causing the agent to operate on the wrong tab.

Example

Before (unstable): 1 2 3 4 5 → close tab 3 → 1 2 3 4 (all indices after 3 shift)

After (stable): 1 2 3 4 5 → close tab 3 → 1 2 4 5 → new tab → 1 2 4 5 6

Problem

When agent-browser connects to a user's Chrome via CDP, it discovers all open tabs and stores them in a Vec<PageInfo>. The tab index exposed to the agent is simply the array position (enumerate). If the user closes or opens tabs in the browser while the agent is working, the array shifts and all subsequent tab_switch/tab_close calls target the wrong tab.

This is especially critical for the CDP use case where the agent shares the browser with a human user.

Solution

Introduce a monotonically increasing, never-reused tab ID mapping (tab_ids: HashMap<String, usize>) keyed by CDP target_id. Each tab is assigned an ID on first discovery, and that ID persists until the tab is destroyed. Deleted IDs are never recycled.

• tab_list returns stable IDs instead of array indices
• tab_switch/tab_close resolve the stable ID back to the internal array position via the mapping
• CLI output (output.rs) reads the index field from the daemon response instead of using its own enumerate

Files Changed

• cli/src/native/browser.rs — BrowserManager gains tab_ids + next_tab_id; all tab operations use stable IDs
• cli/src/output.rs — Tab display reads index from daemon response instead of local enumerate

[vercel]

@yangyaofei is attempting to deploy a commit to the Vercel Labs Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

Additional Suggestion:

The e2e_tabs test uses 0-based array indices for tab operations, but the tab system was changed to use 1-based stable IDs, causing three assertion/runtime failures.