Here is the thing nobody tells you about AI agents and browsers. The agent is smart. The browser is yours. And the two do not meet, because your browser holds your logins, your sessions, your accounts, and the agent holds none of that. So every browser automation tool before now made you choose: either hand the agent a sterile, logged-out browser it can barely do anything with, or let it loose in your real one and watch it hijack the tab you were reading. BrowserSkill, an open-source project from Tencent, refuses the choice. It connects agents like Cursor, Claude Code, Codex, OpenClaw, CodeBuddy, WorkBuddy, Pi, Hermes Agent and DeepSeek Harness to your already logged-in browser, and it does the work in a separate window so you keep working. How? That is what the rest of this piece is about.
Think about what an agent can and cannot reach. It can write code, run shell commands, read files. But the moment a task touches a website that needs your account, it hits a wall. Your email, your internal dashboards, your admin panels, all of it sits behind a login the agent does not have.
Video credit: The Stack
The usual answers are all bad. Spin up a fresh automation browser: now nothing is logged in, and you are managing separate test accounts. Give the agent your cookies or passwords: a security mess. Let it drive your actual browser window: now it is moving your mouse, stealing your focus, closing your tabs. You become a spectator at your own desk.
So the real question is not "can an agent use a browser". It can. The question is: can it use your browser, with your sessions, without taking the machine away from you. BrowserSkill's answer is yes, and the mechanism is worth understanding because it is genuinely simple.
Two local pieces. That is the whole runtime. A command-line tool called bsk, which runs a small local daemon, and a browser extension. Nothing in the cloud, nothing routed through someone else's servers.
The chain goes like this. The agent never talks to the browser directly. It calls the bsk CLI through the shell, the same way it would call any other tool. The CLI passes the request to the local daemon over local IPC. The daemon talks to the extension over a WebSocket on 127.0.0.1. And the extension does the actual browser work, inside a dedicated, visible Agent Window that is separate from your normal windows.
Why does this architecture matter? Two reasons.
That borrowing rule is the interesting part. The default posture is: hands off the user's stuff. The agent asks, you approve, it returns the tab. Not the other way around.
Because the extension lives in your real browser profile, the agent works with sites you are already signed into. No separate test accounts, no credential handoff. The session you built by logging in like a normal person is the session the agent uses.
And when the task hits something only a human can do, a captcha, a login screen, a confirmation dialog, the agent can ask you to take over, then continue afterwards. This is not a hack. It is a designed feature, and as we will see, it is configurable down to the last switch.
The recommended path is almost funny in how little it asks of you. Already using Cursor, Claude Code, Codex or another shell-capable agent? Copy one line and send it to your agent. It installs the CLI and the skill, then walks you through the extension:
Set up browser-skill on this machine by following https://raw.githubusercontent.com/Tencent/BrowserSkill/main/AGENT_INSTALL.md
That is it. The agent does the setup. Which is fitting: a tool for agents, installed by an agent.
The manual path is not much harder. Four steps.
On macOS or Linux, the recommended install goes to ~/.local/bin:
curl -fsSL https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.sh | sh
export PATH="${BSK_INSTALL_DIR:-$HOME/.local/bin}:$PATH"
On Windows, from PowerShell, also installing to ~/.local/bin:
irm https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.ps1 | iex
One detail that bites people: the export makes the CLI available in the current Unix shell. A running agent may need the same PATH setting in each shell call, or the installed binary's absolute path. If the agent retains an old PATH after installation, restart it. Then verify the binary in the terminal or agent environment that will actually use it:
bsk --version
Chrome and Microsoft Edge are supported, and the extension is in both stores: the Chrome Web Store and Edge Add-ons. On other Chromium-based browsers, install the Chrome Web Store build; they are expected to work when they support unpacked Chromium extensions. Firefox is planned, not here yet.
BrowserSkill ships a skill that teaches your agent harness how to use bsk. For the supported harnesses, one command:
bsk install-skill
Press Space to select the harness, Enter to install. For non-interactive installation, name the harness explicitly, for example bsk install-skill --harness cursor --json, which also works when the harness is not detected. --yes alone installs into every detected harness and fails when none are detected. Run bsk install-skill --list to see internal variants and install paths.
Want your own instructions instead of the bundled ones? bsk install-skill --harness cursor --source ./SKILL.md. An explicit --source stays custom even if its contents match the bundled skill, and existing installations are skipped unless you add --force. Other shell-capable harnesses work too: copy skill/SKILL.md into the harness's skills directory as browser-skill/SKILL.md. DeepSeek Harness is the exception, it uses a dedicated plugin instead, more on that below.
Run bsk doctor and follow its hints. Open the extension popup and confirm it is connected. Resolve failures before testing browser use. One caveat worth knowing: doctor can pass with no skill installed (it reports N/A), so verify skill discovery separately.
Then the first real test. Start a new agent session, confirm browser-skill is available, and ask it to open https://example.com and summarize the page. For harnesses with slash-command invocation:
/browser-skill open example.com and summarize what is on the page.
A successful first run reads the page and stops its BrowserSkill session. If the skill is missing, check the target harness and install path before retrying.
The platform matrix is broad. Operating systems: macOS on Apple Silicon and Intel, Linux on x64 and ARM64, Windows x64. Browsers: Chrome and Edge supported, other Chromium browsers expected to work, Firefox planned.
Running inside an agent sandbox that reaps background processes after each command? There is a documented setup for that: keep the daemon in a persistent host environment and connect with a shared BSK_HOME plus BSK_AUTO_START=0. Ordinary local use keeps automatic startup by default. And if you want the agent on a server while the browser stays on your desk, you can pair them using the built-in authentication service or a compatible gateway, covered in the remote browser connections documentation.
This is the part that changed most recently, and the part that decides how much you trust the machine. The extension popup has two independent Automation settings, both enabled by default: "Confirm before borrowing tabs" and "Allow requests for human help". Your saved browser settings are authoritative for every session. Not the CLI flags. The browser settings.
The four combinations behave exactly as you would expect:
Settings save automatically for the browser profile and apply to existing and new sessions. Turning confirmation off releases pending borrow confirmations; turning help off finishes pending help requests as disabled. Turning either back on restores its behavior for subsequent operations. Completed borrows are not undone, and finished help requests are not reopened.
Here is the upgrade note that matters. In version 0.3.0, --unattended, tab borrow --no-confirm and BSK_REQUEST_HELP=off no longer bypass confirmation or disable help. They remain accepted for compatibility, but they are deprecated and cannot override the browser switches. The CLI logs a notice when they are used. Scripts that relied on these inputs alone to avoid waiting must now use the extension settings. session start --json and session list --json report the browser's effective interaction policy, so scripts can read the truth instead of guessing.
Why the change? Because a command-line flag is a terrible place for a consent decision. The user sitting in front of the browser should own that switch, and now they do.
When help is off, request-help returns disabled without confirming any human action. The skill then directs the agent to re-observe and make reasonable efforts to complete authorized steps using existing login state, authorized inputs and available tools. Where task authorization and host rules allow, models with image understanding may attempt graphical verification. But some walls stay walls: phone-only QR scans, face verification, unavailable SMS codes, and image-only captchas for text-only models may remain blocked. A disabled result neither completes the task nor grants additional permission. Good. A blocked agent should stay blocked.
A few details for people running staggered upgrades. Protocol 1.3 retains connection compatibility with protocols 1.0 through 1.2, and ordinary sessions and default tab borrowing keep working during upgrades. Custom borrowing waits require both daemon and extension at protocol 1.2 or later. The current CLI requires daemon protocol 1.3 for request-help, because older daemons can answer locally without consulting the browser, which would defeat the whole point. The popup identifies older daemons and bsk status reports protocol differences. The clean move is to update the CLI, the running daemon and the extension together.
What does a normal day with this look like? Start tasks with bsk session start; add --no-focus if you do not want the Agent Window stealing focus. For unattended operation, turn off the corresponding settings in the extension, not on the command line.
Need a full-page capture? Two ways. From the extension: Quick actions, then Full-page screenshot. From the agent: bsk screenshot --session <id> --full-page --out page.png. A full-page screenshot guide covers page support, cancellation and export. Note that new features like full-page screenshots need matching builds of the CLI, daemon and extension, so check versions with bsk --version and bsk status if something is missing.
Updating is one command for the default local setup, once active browser tasks finish:
bsk update --yes
It restarts a running daemon with default startup settings. If you replaced the binary with the installer instead, restart the existing daemon with bsk daemon restart. On Windows, if a staged update is reported, wait for the replacement to finish before checking bsk --version. For a custom port, a host-managed sandbox daemon or a remote server, stop the daemon in its owning host, run bsk update --yes --no-restart-daemon, and start it there with its original flags and BSK_HOME. The extension updates through its browser store, and store availability may lag the CLI release.
DeepSeek Harness users get a first-class path. BrowserSkill ships a dsh plugin on npm as @wxg-prc-cpg/browser-skill-dsh-plugin. It gives the agent native browser_* tools and a live view of its browser sessions in the Web UI, and the plugin runs bsk on the agent's behalf. Same chain as everything else, just with the plugin doing the calling.
Install the bsk CLI and connect the extension first. Then add the plugin to a dsh profile and start it (replace web with your profile name):
dsh plugin --profile web add @wxg-prc-cpg/browser-skill-dsh-plugin
dsh --profile web
The plugin includes the browser-skill skill, so bsk install-skill is not needed for dsh. Installed plugins do not update automatically; to upgrade, run dsh plugin --profile web update @wxg-prc-cpg/browser-skill-dsh-plugin --latest and restart the profile afterwards.
The repository is a Cargo plus pnpm workspace, written primarily in TypeScript with the CLI and daemon in Rust, and licensed under MIT. The layout:
That last piece deserves a sentence. The project ships its own evaluation setup with deterministic local pages, so browser capabilities can be tested without depending on the live web. There is also a scroll-to primitive reference covering its CLI, protocol and plugin entry points, visible bounds and interruption behavior.
What is not there yet? Firefox, which is planned but not shipped. Some human-only barriers stay human-only when help is disabled: face verification, phone-only QR scans, SMS codes you cannot reach. And the consent model, while much cleaner in 0.3.0, asks mixed-version installations to update all three pieces before the settings are fully enforced.
None of that changes the core bet. The agent ecosystem is fragmenting into harnesses, frameworks and models, and BrowserSkill's bet is that the browser connection should not fragment with it. One CLI, one extension, any agent that can call a shell. The web you are already logged into, borrowed politely and returned when done.
Yes. Any agent that can call a shell can use BrowserSkill through the bsk CLI, with no lock-in to a specific model, framework or harness. The README names Codex, OpenClaw, CodeBuddy, WorkBuddy, Pi and Hermes Agent alongside Cursor and Claude Code, and DeepSeek Harness connects through a dedicated npm plugin instead.
Yes, but the switch lives in the browser, not the CLI. Turn off "Confirm before borrowing tabs" and "Allow requests for human help" in the extension popup's Automation settings, and tasks run unattended. Since version 0.3.0, the old --unattended flag and BSK_REQUEST_HELP=off environment variable are deprecated and cannot override those browser settings.
It depends on the help setting. With help requests allowed, the agent s and hands the step to you, then picks the task back up once you are done. With help turned off, the request-help call comes back disabled, and the agent is told to push on with the login state and inputs it already has. Even then, some barriers do not move: a QR code that only a phone can scan, a face check, or an image-only captcha facing a text-only model can still stop the task cold.
Yes. You can pair an agent running on a server with your local browser using the built-in authentication service or a compatible gateway. The setup is covered in the project's remote browser connections documentation.
BrowserSkill solves a specific, annoying problem with a specific, clean mechanism: a local CLI and daemon, a browser extension, a separate Agent Window, and a consent model that keeps the human in charge of their own tabs. It reuses the login state you already have, it works with any shell-capable agent, and it is MIT-licensed. If your agents keep bouncing off the logged-in web, this is the bridge.