BrowserSkill: Letting AI Agents 'Borrow' Your Browser Tabs
The Scenario: You're Reviewing a PR, and Your Agent Wants Your Browser
Picture this: you're reviewing a PR in your browser, logged into GitHub, Jira, and Slack. Your AI agent (Claude Code, Cursor, or Codex) says: "I can merge this PR for you, but I need access to your browser."
Traditional options all fall short:
- Give the agent a headless browser — but it has none of your login state, so it can't do anything.
- Give it an API key — but not every service has an API.
- Let it launch a new browser via Playwright — but it must log in again from scratch, hitting two-factor authentication, CAPTCHAs, and device verification.
- A browser extension: A Chrome/Edge extension communicates with your browser. It knows your tabs and which services are logged in.
- A local daemon: The
bskCLI talks to a local daemon, which talks to the extension. This chain ensures the agent never directly touches your cookies or sessions. - Session isolation: While borrowing a tab, the agent operates in an isolated session context. Your other tabs can't see the agent's actions, and the agent can't see your other tabs.
- Operations requiring login state: reviewing GitHub PRs, updating Jira tickets, filling forms on intranet systems — cases where API keys are unavailable or insufficient.
- Agent + human collaboration: the agent handles most steps; the human handles CAPTCHAs and confirmations.
- Multi-agent parallelism: different agents borrow different tabs and work independently.
- Requires a browser extension: Firefox not yet supported (planned); no Safari.
- Local only: agent and browser must be on the same machine; no remote agent operating a remote browser.
- Single-user design: no multi-user sharing of one browser instance.
Tencent's BrowserSkill offers a fourth answer: let the agent "borrow" tabs you already have open. It returns them when done, and your other tabs are unaffected.
The "Tab Borrowing" Model: From "Simulating Humans" to "Collaborating with Humans"
For the past decade, browser automation has been about "simulating humans." Selenium simulates clicks, Playwright simulates user behavior, Puppeteer simulates keyboard input. The implicit assumption: the browser is the tool, the agent is the operator, and the human is a bystander.
BrowserSkill flips this assumption: the browser is the human's workspace, and the agent is a borrowing visitor.
The mechanism works like this:
1. Agent Window: BrowserSkill opens a dedicated Agent window inside your browser, separate from the window you're using. You keep working while the agent works in its own window.
2. Explicit borrowing: When the agent needs to access one of your logged-in tabs, it must explicitly declare "I want to borrow this tab" via the bsk CLI. No silent scraping, no background monitoring — an explicit request.
3. Return after use: When the task completes, the tab is returned. The agent cannot retain access.
4. Human-in-the-loop: When hitting a CAPTCHA, login confirmation, or 2FA, the agent pauses and asks you to step in. You click, and it continues.
Together, these four mechanisms form a permission model: the agent's browser access is neither "all or nothing" but "borrow on demand, return after use, human intervention at critical points."
Why "Borrowing Tabs" Is Harder Than "Launching a New Browser"
Technically, borrowing tabs is far harder than spinning up a new browser. It requires:
The cost: you must install a CLI and a browser extension. The payoff: the agent can access all your logged-in services without any API keys or passwords.
"Any Shell-Capable Agent Can Use It": CLI as a Universal Interface
A key design decision: BrowserSkill is not tied to any specific agent framework. All functionality is exposed via the bsk CLI, so any agent that can call a shell can use it.
This means Cursor, Claude Code, Codex, and other agents just need to add one capability — "invoke a bsk command" — to gain browser control. This recalls the Unix philosophy: tools should communicate through text streams, not shared memory. Compared to Playwright's Python/Node SDK bindings or browser-use's Python-first design, the CLI-first strategy is a smart choice in today's fragmented agent ecosystem.
The Agent Window: From "Shared Screen" to "Parallel Desktops"
Traditional tools either run headless (you can't see what's happening) or take over your full browser (you can't work). The Agent Window is a third path: your browser window and the agent's window coexist in parallel without interfering. You can see what the agent is doing (visibility) without giving up your browser (no interruption).
The underlying judgment: agent browser operations mostly don't need human supervision, but occasionally need human intervention — more realistic than "fully automatic" or "fully manual."
Comparison with Other Browser Automation Approaches
| Dimension | Playwright/Puppeteer | browser-use | BrowserSkill |
|-----------|---------------------|-------------|--------------|
| Login state | None (fresh instance) | None (fresh instance) | Yes (borrows real tabs) |
| Framework binding | SDK-bound | Python-first | CLI-first, any shell agent |
| Human intervention | None | Screenshot + click | Explicit human-in-the-loop |
| User browser interruption | No (separate instance) | No (separate instance) | No (Agent Window) |
| Install complexity | pip install | pip install | CLI + browser extension |
BrowserSkill's unique edge is the "login state" column. Other tools solve "how to simulate a human operating a browser"; BrowserSkill solves "how to let an agent reuse browser sessions a human has already established."
Use Cases and Limitations
Best suited for:
Limitations:
The Deeper Insight: From "Agent Simulating Humans" to "Agent Collaborating with Humans"
Behind the "tab borrowing" model is a bigger paradigm shift: agents no longer try to fully replace humans operating the browser — they share the browser with humans.
This shift acknowledges that agents still need humans for certain operations (CAPTCHAs, 2FA, complex decisions), rather than pretending these don't exist. And it lets agents leverage login states humans have already established, instead of re-simulating the login process from scratch.
From a security perspective, the model is also more auditable: the agent's access is borrowed, temporary, and revocable — not owned, permanent, and unauditable. Every tab borrowing is an explicit event that can be logged and audited.
---
The BrowserSkill GitHub repo is at https://github.com/Tencent/BrowserSkill — 1,350 stars in a day signals a real pain point. If you use Claude Code, Cursor, or Codex and frequently need agents to operate logged-in services in your browser, BrowserSkill is worth a try.
"Tab borrowing" may become the standard interaction pattern between agents and browsers. Like borrowing a car versus renting one — more convenient, as long as you trust the borrower.