{"slug": "browserskill-ai-agents-in-your-real-browser", "title": "BrowserSkill: AI Agents in Your Real Browser", "summary": "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.", "body_md": "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.\n\nThink 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.\n\n*Video credit: The Stack*\n\nThe 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.\n\nSo 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.\n\nTwo 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.\n\nThe 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.\n\nWhy does this architecture matter? Two reasons.\n\nThat 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.\n\nBecause 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.\n\nAnd 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.\n\nThe 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:\n\n```\nSet up browser-skill on this machine by following https://raw.githubusercontent.com/Tencent/BrowserSkill/main/AGENT_INSTALL.md\n```\n\nThat is it. The agent does the setup. Which is fitting: a tool for agents, installed by an agent.\n\nThe manual path is not much harder. Four steps.\n\nOn macOS or Linux, the recommended install goes to `~/.local/bin`:\n\n```\ncurl -fsSL https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.sh | sh\nexport PATH=\"${BSK_INSTALL_DIR:-$HOME/.local/bin}:$PATH\"\n```\n\nOn Windows, from PowerShell, also installing to `~/.local/bin`:\n\n```\nirm https://raw.githubusercontent.com/Tencent/BrowserSkill/main/install.ps1 | iex\n```\n\nOne 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:\n\n```\nbsk --version\n```\n\nChrome 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.\n\nBrowserSkill ships a skill that teaches your agent harness how to use `bsk`. For the supported harnesses, one command:\n\n```\nbsk install-skill\n```\n\nPress 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.\n\nWant 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.\n\nRun `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.\n\nThen 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:\n\n```\n/browser-skill open example.com and summarize what is on the page.\n```\n\nA 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.\n\nThe 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.\n\nRunning 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.\n\nThis 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.\n\nThe four combinations behave exactly as you would expect:\n\nSettings 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.\n\nHere 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.\n\nWhy 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.\n\nWhen 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.\n\nA 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.\n\nWhat 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.\n\nNeed 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.\n\nUpdating is one command for the default local setup, once active browser tasks finish:\n\n```\nbsk update --yes\n```\n\nIt 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.\n\nDeepSeek 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.\n\nInstall 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):\n\n```\ndsh plugin --profile web add @wxg-prc-cpg/browser-skill-dsh-plugin\ndsh --profile web\n```\n\nThe 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.\n\nThe repository is a Cargo plus pnpm workspace, written primarily in TypeScript with the CLI and daemon in Rust, and licensed under MIT. The layout:\n\nThat 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.\n\nWhat 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.\n\nNone 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.\n\nYes. 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.\n\nYes, 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.\n\nIt 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.\n\nYes. 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.\n\nBrowserSkill 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.", "url": "https://wpnews.pro/news/browserskill-ai-agents-in-your-real-browser", "canonical_source": "https://dev.to/diflowrin/browserskill-ai-agents-in-your-real-browser-3pla", "published_at": "2026-09-17 21:20:53+00:00", "updated_at": "2026-09-17 21:22:54.826318+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "agent-protocols"], "entities": ["Tencent", "BrowserSkill", "Cursor", "Claude Code", "Codex", "OpenClaw", "CodeBuddy", "DeepSeek"], "alternates": {"html": "https://wpnews.pro/news/browserskill-ai-agents-in-your-real-browser", "markdown": "https://wpnews.pro/news/browserskill-ai-agents-in-your-real-browser.md", "text": "https://wpnews.pro/news/browserskill-ai-agents-in-your-real-browser.txt", "jsonld": "https://wpnews.pro/news/browserskill-ai-agents-in-your-real-browser.jsonld"}}