Seeing Is Not Acting: Tabs, Claims, and Borrowing

BrowserSkill makes a deliberate distinction between a tab an agent can discover and a tab it may control. This chapter focuses on that distinction: how local and remote sessions classify tabs, what explicit borrowing records beyond a tab ID, and why confirmation, cross-session isolation, and return handling are part of the action itself. The practical judgment is simple to state but easy to miss: before an agent acts, it must know whether the target is visible, owned, borrowed, or outside the session's authority.

A tab can be visible without belonging to the task

The browser presents tabs as a flat collection, but BrowserSkill does not treat them as a flat permission set. A session can ask for user tabs, its own Agent Window tabs, or both. Tabs inside another session's Agent Window are filtered out rather than presented as ordinary user tabs. This matters because a second task may be using a similar page, and because a window boundary without a session boundary would make concurrent work easy to confuse.

The system also distinguishes membership from ownership. The Agent Window is the session's operating space, but not every tab that appears there becomes agent-controlled automatically. The home tab created for the session is claimed. A tab created through the session's explicit tab-creation path is claimed as well. A tab opened by Chrome's user interface or by a page—perhaps through a popup or a new-window link—does not gain authority merely by appearing in the same window. Browser event order is not a substitute for an ownership decision.

This produces several useful categories. A user tab may be visible so the agent can identify which page the user wants to lend to the task. A tab in the session's Agent Window may be the task's own tab, or it may still require a separate claim depending on how it arrived there. A borrowed tab is a user resource that has crossed into the session's controlled space under an explicit record. A tab belonging to another session is not a candidate for either task. The tab ID alone cannot express these distinctions.

Local and remote sessions apply the distinction differently. In local mode, passive reads can be available for a visible user tab, while tools that dispatch page input or mutate browser state remain constrained to the Agent Window. That policy recognizes a difference between looking at a page and changing it, while still keeping writes in a visible task window. Remote mode is stricter: reading, screenshotting, recording, or operating a user tab requires that the task created it or explicitly borrowed it. Listing titles and URLs can still help the agent choose a target, but discovery does not become authorization simply because the agent is running on a server.

The difference is not a promise that passive reading is consequence-free. A page can display sensitive information, and a screenshot or recording can preserve what was visible. The point is that BrowserSkill assigns a different control requirement to observation than to page input, and then tightens both for remote tasks because the server is farther from the person whose browser is being used.