BrowserSkill: AI Agents in Your Real Browser Tencent has open-sourced BrowserSkill, a tool that lets AI coding agents such as Cursor, Claude Code, and Codex drive a user's already logged-in browser without hijacking their active tabs. The system runs a local CLI daemon (`bsk`) plus a browser extension that communicate over local IPC and a 127.0.0.1 WebSocket, executing agent tasks in a separate visible Agent Window while borrowing the user's real sessions with approval. It is aimed at letting agents reach authenticated sites like email and internal dashboards without credential handoff or sterile test browsers. 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 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. 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