Safer tab targeting for local ThinkRun sessions

2026-07-27

When an agent opens an isolated browser window, it needs a reliable way to keep working in that window. Before this update, thinkrun --tab <id> could fail even when the tab belonged to the same local session. The command omitted the session identity that the local browser bridge uses to recognize its owner.

That made a safe workflow unnecessarily awkward: open a window, then address it by its tab id without being affected by whatever tab a person was currently viewing.

What changed

For a --tab <id> command, ThinkRun now forwards the active session identity only when the selected tab is locally confirmed as self-owned and it matches that session's current tab binding. That lets an agent continue working in the isolated window it opened.

The behavior remains deliberately narrow:

• Unowned tabs are still accessed anonymously, preserving the existing local workflow for those tabs.
• A tab locked by another local agent is still rejected before the command reaches the browser.
• The browser's native host remains the authoritative ownership check.

So this is not a broader permission change. It fixes identity forwarding for the session that already owns the target tab, while keeping cross-agent isolation intact.

A practical example

After opening an isolated window, an agent can use its returned id directly:

thinkrun new-window https://example.com
thinkrun evaluate --tab <returned-tab-id> 'document.title'

The second command now carries the identity of the session that owns that tab. If another agent tries the same command against your tab, it remains blocked.

This update applies to the local CLI tab-targeting path. It does not change MCP behavior.