BrowserSkill: Let AI Agents Drive the Browser You Are Already Logged Into

BrowserSkill is Tencent's answer to a problem that every browser-automation tool runs into about ten minutes in: the browser your agent drives is signed into nothing.

It is MIT licensed, passed 3,600 GitHub stars within three months of the repository being created, and connects Cursor, Claude Code, Codex, OpenClaw, CodeBuddy, WorkBuddy, Pi, Hermes Agent and DeepSeek Harness to the browser profile you are already using.

The mechanism is a local CLI called bsk plus a browser extension. Any agent that can run a shell command can use it, which is a deliberately low bar and the reason the supported-harness list is so long. There is no SDK to adopt and no framework to buy into.

Ask an agent to check your orders, pull a report from an internal dashboard, or file a ticket, and a conventional automation stack hits the same wall. Playwright, Puppeteer and the agent frameworks built on them launch a clean browser context. Clean means no cookies, no session, no SSO, no saved MFA device. From the site's point of view it is a stranger on a new machine.

The usual workarounds are all bad in their own way:

• Separate test accounts. Fine for a staging environment, useless when the task is "look at my account".
• Copying cookies or a profile directory into the automation browser. Fragile, frequently trips bot detection, and means your live session tokens are now sitting somewhere else.
• Storing credentials for the agent to type. You have now given a language model your password and put it through a login flow that will very likely ask for a second factor anyway.
• Running the agent in your actual browser. It works right up until the agent takes over the window you are using.

BrowserSkill's answer is the fourth option done properly. It uses your real profile, with your real sessions, but it does the work in a separate Agent Window so your own browsing is untouched.

This space got crowded fast, and four things now sound almost identical. The differences are real and worth knowing before you pick one.

The dividing line is whether the tool brings its own browser or borrows yours. browser-use and agent-browser bring their own, which is the right shape for scraping, testing and CI, where a clean deterministic context is a feature rather than a limitation.

BrowserSkill and Claude in Chrome borrow yours. Between those two, the difference is whether you keep working. Claude in Chrome operates in the tab in front of you. BrowserSkill opens its own window and leaves your tabs alone unless it explicitly asks for one.

If your task genuinely does not need a login, a headless tool is simpler and faster. BrowserSkill earns its complexity only when the session is the point.

Most of the time the agent works in its own Agent Window and never touches your browsing. Sometimes that is not enough, because the thing you want it to act on is a tab you already have open with state in it that cannot be reproduced by navigating to a URL.

For that case there is an explicit borrow. The agent has to ask for the tab, it gets it only when the borrow is approved, and it returns it when the task finishes. The rest of your browser stays out of scope for the whole session.

This is a better model than it first appears. The alternative designs are "the agent can see everything you have open", which is a privacy problem, or "the agent can see nothing you have open", which is a capability problem. An explicit, per-tab, time-bounded handover is the narrow path between them, and it is the part of this design most worth copying.

tab borrow --timeout 60s controls how long the confirmation prompt waits, not whether confirmation happens at all. That distinction catches people out.

Any tool that drives a real logged-in browser eventually meets a captcha, an unexpected re-login, a confirmation dialog, or a payment step. Most automation either fails there or, worse, tries to grind through it.

BrowserSkill has a first-class request-help path. The agent pauses, you take over in the Agent Window, you clear the human-only step, and the agent continues from where it stopped. The session is not lost and the work does not have to restart.

The honest limits are documented rather than hidden. When help is disabled, the agent is told to re-observe and make reasonable efforts with the login state and inputs it already has, and models with image understanding may attempt graphical verification where the task authorization allows it. Phone-only QR scans, face verification, SMS codes you cannot access, and image-only captchas facing a text-only model stay blocked. A disabled result does not complete the task and does not grant extra permission, which is the correct behaviour and a refreshingly unglamorous thing to put in a README.

The agent never talks to your browser directly. There are four hops, and every one of them is local.

flowchart TB
  Agent["Agent: Cursor, Claude Code, Codex"]
  CLI["bsk CLI"]
  Daemon["bsk daemon"]
  Ext["BrowserSkill extension"]
  AW["Agent Window"]
  UW["Your normal windows"]
  Agent -->|"shell: bsk ..."| CLI
  CLI -->|"local IPC"| Daemon
  Daemon -->|"WebSocket on 127.0.0.1"| Ext
  Ext -->|"automates"| AW
  Ext -.->|"borrow only when asked"| UW

The agent runs a shell command. The CLI passes it to a local daemon over IPC. The daemon reaches the extension over a WebSocket bound to 127.0.0.1. The extension does the work in the Agent Window.

Two things follow from that shape. First, the loopback binding means nothing is listening on a network interface by default, though there is an opt-in path for pairing a server-side agent with your local browser through an authentication service. Second, because the whole contract is "run a shell command", any agent with shell access works without an integration being written for it. DeepSeek Harness is the exception that proves the rule: it gets a dedicated npm plugin exposing native browser_* tools, and that plugin just runs bsk underneath.

Under the hood the repository is a Cargo and pnpm workspace. The CLI and daemon are Rust, the extension and plugin are TypeScript. GitHub labels the repo TypeScript because that is the bulk of the line count, which slightly undersells the Rust core.

If you want to render that architecture diagram yourself, the source above is Mermaid and our Mermaid converter will turn it into an image you can drop into your own notes.

There is a lazy path and a manual path, and the lazy one is genuinely the recommended one.

Let the agent do it. Paste this to any shell-capable agent and it installs the CLI and skill, then walks you through loading the extension:

Set up browser-skill on this machine by following https://raw.githubusercontent.com/Tencent/BrowserSkill/main/AGENT_INSTALL.md

Or do it yourself, in four steps. Install the CLI:

curl -fsSL https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.sh | sh
export PATH="${BSK_INSTALL_DIR:-$HOME/.local/bin}:$PATH"

Windows uses irm ... install.ps1 | iex in PowerShell. Then install the extension from the Chrome Web Store or Edge Add-ons, run bsk install-skill to teach your harness how to call bsk, and finish with bsk doctor.

A PATH detail worth knowing, because it produces a confusing first failure: a running agent may hold an old PATH and not see the new binary. Restart the agent, or give it the absolute path. bsk doctor can also pass with no skill installed, reporting N/A, so a green doctor is not proof your harness can actually find the skill. Verify that separately by starting a session and checking browser-skill is listed.

The extension popup has two Automation settings, both on by default, and they are the real security boundary:

• Confirm before borrowing tabs. Off means the agent takes tabs without asking.
• Allow requests for human help. Off means request-help returns disabled instead of pausing for you.

Your saved browser settings are authoritative. This changed in 0.3.0 and it is the single most important thing to know if you are upgrading. --unattended, tab borrow --no-confirm and BSK_REQUEST_HELP=off no longer bypass confirmation or disable help. They are still accepted for compatibility, they are deprecated, and they cannot override the switches. Scripts that relied on those flags alone to run unattended will now sit waiting for a confirmation that nobody is there to give.

That is the right call. A command-line flag travels with whatever the agent decided to run; a browser setting is a decision a human made once, in the browser, deliberately. Moving authority from the former to the latter is exactly the direction it should move.

One more upgrade trap: request-help needs daemon protocol 1.3, because older daemons could answer it locally without ever consulting the browser. Update the CLI, the daemon and the extension together, then check with bsk status and bsk doctor.

Firefox being planned rather than supported is the notable gap, since the extension model differs enough that it is real work rather than a recompile.

If your agent runs in a sandbox that reaps background processes between commands, the default automatic daemon startup will not survive. The project documents that case: keep the daemon in a persistent host environment and connect with a shared BSK_HOME and BSK_AUTO_START=0.

There is also a full-page screenshot primitive, either from Quick actions in the popup or as bsk screenshot --session <id> --full-page --out page.png, which is more useful than it sounds when you want the agent to hand you visual evidence of what it did.

Be clear about what this does, because the convenience and the risk are the same feature.

You are giving an autonomous agent the ability to act as you, on every site you are currently signed into, using sessions that have already cleared MFA. Your bank, your email, your company's admin panels. Not credentials, which is genuinely better, but live authenticated sessions, which for most purposes is the same power.

The design takes this seriously. Work is confined to a separate window, tab borrowing is confirmed, the daemon is loopback-bound, and the safety switches now live in the browser where a flag cannot override them. That is a thoughtful threat model rather than a box-ticking exercise.

It still cannot protect you from the obvious failure: prompt injection. A page the agent reads can contain instructions aimed at the agent, and the agent is holding your logged-in session while it reads. That is not a BrowserSkill flaw, it is the open problem for this entire category, and no tool here has solved it.

Practical advice. Leave both switches on. Use a browser profile that is not signed into your most sensitive accounts, which costs you very little and removes most of the downside. Watch the Agent Window for the first few runs rather than trusting it immediately. If you want to sanity-check what a given profile actually exposes before you point an agent at it, our IP checker shows what a site sees when that browser connects.

For the tasks it is built for, which are the ones where the login is the whole difficulty, it is the most carefully built option in the category right now.