BrowserSkill: letting shell-capable agents borrow a logged-in Chrome tab

The tab-borrowing model, and why it is not headless automation

Most agent browser tools start a fresh profile, log in again, and run without a visible window. BrowserSkill takes the opposite position. The README states that an agent needing a tab you already have open must borrow that tab explicitly, return it when the task is done, and leave the rest of your browser alone. That single constraint explains most of the project's shape.

The audience is narrow and specific. The README lists Cursor, Claude Code, Codex, OpenClaw, CodeBuddy, WorkBuddy, Pi, Hermes Agent and DeepSeek Harness as targets, and the stated requirement is only that an agent can call a shell. There is no model lock-in and no framework lock-in. If your agent can run a command, it can call bsk. The problem being solved is the one where a site you are signed into has no API, or the API path is blocked, and re-authenticating inside an agent-controlled profile is either impossible (hardware key, SSO, captcha) or against the site's terms.

The trade-off is visibility. Browser tasks run in a separate, visible Agent Window, described as a way to keep working in your own browser. That is not an invisibility feature. It is a separate window you can watch, which is a deliberate choice about trust and about not hijacking the tabs you are using.

Two runtimes: the bsk daemon and the unpacked extension

The architecture has exactly two local pieces, and the README is explicit that both are required: the bsk CLI/daemon, and the browser extension. The CLI is the surface the agent talks to. The extension is what actually reaches into the browser. Neither is useful alone.

Platform support as documented: macOS on Apple Silicon and Intel, Linux on x64 and ARM64, Windows x64. Chrome and Microsoft Edge are the supported browsers. Other Chromium-based browsers are expected to work when they support unpacked Chromium extensions, which is a hedge rather than a guarantee. Firefox is listed as planned, not shipped.

The extension is distributed through store listings (Chrome Web Store and Edge Add-ons), and the README tells users on other Chromium browsers to install the Chrome Web Store build. The CLI is distributed as a shell script for macOS and Linux and a PowerShell script for Windows. The daemon is the part that needs to stay alive between agent commands, which becomes the central operational concern on sandboxed setups.

Install path: one line for the agent, or three manual steps

The recommended route is to hand the agent a single instruction pointing at the repository's AGENT_INSTALL.md, which the README says will install the CLI and skill and then walk the user through loading the extension. The manual route has three steps.

Install the CLI. On macOS and Linux, the documented command is curl -fsSL https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.sh | sh, which installs to ~/.local/bin. On Windows, the PowerShell equivalent is irm https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.ps1 | iex, also into ~/.local/bin. Then verify with bsk --version.

Install the extension from the Chrome Web Store or Edge Add-ons listing.

Install the skill, which is what teaches the agent harness how to call bsk. The command is bsk install-skill, which presents a selector: Space to pick the harness, Enter to install. bsk install-skill --list shows internal variants and install paths. For custom instructions the form is bsk install-skill --harness cursor --source ./SKILL.md. An explicit --source stays custom even if its contents match the bundled skill. Existing installations are skipped unless --force is added.

There is a second configuration surface for sandboxed agents. The README warns that agent sandboxes which reap background processes after each command need the sandboxed agent setup, keeping the daemon in a persistent host environment and connecting with a shared BSK_HOME plus BSK_AUTO_START=0. Ordinary local use keeps automatic startup on by default. Those two keys are the only ones named in the material.

Skill sync: content baselines, WARN states, and deferred installs

The skill update logic is more careful than most projects of this size, and it is worth reading before you edit SKILL.md by hand. Daemon startup, session start, and doctor update managed skills only when their contents still match the last installed version. Local edits are preserved and automatic updates pause. An older installation without a content baseline is enrolled automatically only if it exactly matches the current bundled skill, and that enrollment writes the source marker without rewriting SKILL.md. Explicit custom installations stay custom even when their contents match the bundled skill.

When doctor encounters differing historical files, local edits, or an unrecognized source marker, it prints WARN with the reason and recovery options. The README is clear that these warnings do not fail the health check: with --json the output reports status: "warn" and ok: true. A concurrent install or sync is reported as deferred and retried on a later pass.

That behaviour is a real design decision, not a footnote. It means an agent harness that quietly rewrote its own instructions would be caught, and it means a user who customized SKILL.md will not silently lose those edits on the next daemon start. The cost is that a stale skill can persist without a hard failure, so a WARN in doctor output is something you have to read rather than something that stops you.

Human-in-the-loop is the feature, and the failure mode

The README lists built-in human-in-loop as an advantage: when a task hits captcha, login, confirmation dialogs, or other human-only steps, the agent can ask the user to take over and then continue afterwards. For sites with bot detection, this is the only honest design. It also means BrowserSkill is not a fit for fully unattended pipelines. A job that runs at 3am and cannot wait for a person to click a checkbox is the wrong workload.

There are other boundaries worth naming. Firefox users are told it is planned, so today the answer is no. Non-Chromium browsers are not addressed at all. The README does not state a rate limit, a concurrency model, or what happens when two agents borrow the same tab, so anything about parallel agents is unverified from this material and should be treated as unknown rather than assumed safe.

Running the agent against a signed-in account is the whole point, and it carries the obvious consequence: the agent inherits whatever that session can do. The README's borrowing rule (explicit borrow, explicit return, leave the rest alone) is the project's answer to scope, but scope is enforced by the agent's behaviour and by the daemon, not by a permission system described in the material. If you point it at an admin console, expect admin actions.

How it differs from Playwright and Puppeteer-style automation

Playwright and Puppeteer launch a browser they control, usually with a clean profile, and your test code owns the session. That model is reproducible and scriptable, and it is the right one for CI. It is also exactly what fails when the target site requires an existing authenticated session that you cannot recreate programmatically.

BrowserSkill inverts the ownership. The browser already exists, the session already exists, and the agent borrows a tab from it. The interface is a shell command rather than a library import, which is why any harness that can run a process can use it, and why there is no Node or Python binding to learn. The unit of control is a tab in a visible window, not an isolated browser context.

A closer comparison is raw Chrome DevTools Protocol scripting against your own running Chrome. That gives you the same logged-in session, but you write the automation yourself, you manage the connection, and you handle the human handoff case yourself. BrowserSkill packages the handoff and the skill installation; the price is that you adopt its daemon, its extension, and its tab-borrowing discipline. If you already have a working CDP harness tuned to your own Chrome, the marginal gain here is the agent-facing skill and the install flow, not the underlying reach.

Maintenance cost and the MIT licence

There are two moving parts to keep current. The bsk CLI is installed by a shell or PowerShell script that pulls from the main branch, so re-running the install command is the documented upgrade path, and bsk --version is the check. The extension updates through the Chrome Web Store or Edge Add-ons, which means extension and CLI can drift apart. The release list shows ext-v0.2.1 and cli-v0.2.1 published on the same day, with ext-v0.2.0 a week earlier, which suggests the two are meant to move together. The README does not state a compatibility matrix between CLI and extension versions, so a mismatched pair is an unverified scenario.

The skill layer adds a third thing to maintain, and the content-baseline logic means it mostly maintains itself until you edit it. Once you do, automatic updates pause and doctor reports WARN. That is a deliberate cost: customization buys you stability at the price of manual sync.

The project is MIT licensed, which is permissive and places few obligations on redistribution. This is not legal advice, and the extension's presence in the Chrome Web Store and Edge Add-ons means the store terms apply to that component separately from the repository licence. If you plan to redistribute the extension inside an organization, check the store listing terms rather than the repository LICENSE file alone.

Editorial conclusion

Adopt BrowserSkill if you already live inside a shell-capable agent and need it to act on sites where your login state matters, and if you accept a visible Agent Window rather than a silent headless run. Skip it if you need Firefox today, if your agent runs in a sandbox that reaps background processes without the documented BSK_HOME and BSK_AUTO_START=0 workaround, or if you want unattended automation with no human handoff. Verify first that bsk --version returns after install, that the extension loads from the Chrome Web Store or Edge Add-ons listing, and that bsk install-skill resolves your harness before you point an agent at a production account.

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Tencent/BrowserSkill on GitHub