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.
The problem: agents are locked out of the web you actually use
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: Free Tool Gives AI Agents Full Browser Access
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.
How BrowserSkill actually works
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.
- Any agent can use it. Anything that can call a shell can call bsk. There is no lock-in to a specific model, agent framework or harness. Cursor, Claude Code, Codex, OpenClaw, CodeBuddy, WorkBuddy, Pi, Hermes Agent, all of them connect the same way.
- Your browser stays yours. Tasks run in the Agent Window. If the agent genuinely needs a tab you already have open, it must borrow that tab explicitly, return it when the task is done, and leave the rest of your browser alone.
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.
Reuse your login state, skip the test accounts
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.
Human in the loop, built in
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.
Installing it: one line if you have an agent, four steps if you do not
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 loading 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.
Step 1: install the bsk CLI
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
Step 2: install the browser extension
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.
Step 3: install the skill
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.
Step 4: verify the connection
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.
Where it runs
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.
The automation settings: who approves what
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:
- Both on: borrowing requires approval, help requests show the existing UI.
- Confirm on, help off: borrowing requires approval, help requests return disabled.
- Confirm off, help on: borrowing skips confirmation, help requests show the UI.
- Both off: borrowing skips confirmation, help requests return disabled. Fully unattended.
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.
What changed in 0.3.0
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 disabled
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.
Protocol versions and mixed installations
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.
Everyday workflows
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.
The DeepSeek Harness plugin
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.
Under the hood, for developers
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:
- crates/bsk-cli: the bsk CLI and local daemon
- crates/bsk-protocol: shared wire types and JSON schemas
- apps/extension: the browser extension
- packages/ui and packages/i18n: shared extension UI support, including English, Simplified Chinese and Korean localization
- packages/dsh-plugin-browserskill: the DeepSeek Harness plugin
- evals/browser: deterministic local pages and agent-neutral browser capability evaluation
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.
Limits and what is next
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.
People Also Ask
Does BrowserSkill work with agents other than Cursor and Claude Code?
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.
Can BrowserSkill run browser tasks without asking me for confirmation?
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.
What happens when a task hits a captcha or login screen?
It depends on the help setting. With help requests allowed, the agent pauses 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.
Can I run the agent on a server but use my local browser?
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.
The bottom line
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.
Top comments (1)
The separate window is a strong usability boundary, but Iād also make the permission boundary visible at the action level. A durable audit record should say which tab, origin, and session context were used, plus the exact browser operation. That gives the user a way to review automation after the fact without turning the extension into a silent bearer of every logged-in capability.