Tencent's Browser Agent Skips the Hard Part by Using the Browser You Already Logged Into
Tencent/BrowserSkill picked up roughly 1,350 stars in a single day, taking it to about 4,100, and the pitch is one line: let AI agents use your real, logged-in browser without interrupting your work. Repo at https://github.com/Tencent/BrowserSkill , MIT licensed, 500-plus commits, currently at v0.3.0.
The architecture is three pieces and one rule. A CLI called bsk with a local daemon, a browser extension talking to that daemon over WebSocket, and a separate Agent Window the agent drives. The rule, in their own words: the agent never talks to the browser directly. It asks the bsk CLI to perform a browser task, the daemon routes it to the extension, the extension runs it in the Agent Window. You keep using your own windows the entire time.
That separation is doing more work than it looks like. Every browser-automation tool built on a fresh headless profile runs face-first into the thing nobody wants to write about: authentication. Your session cookies, your SSO, your device trust, your MFA prompts, the enterprise app that fingerprints the browser and locks the account when a datacenter IP shows up. Solving that properly is a multi-quarter security project. Riding the profile you are already signed into makes it disappear, and the visible separate window is the concession to the obvious objection, which is that an agent now has your live credentials to everything.
That tradeoff is real and worth stating without spin. The isolation here is a separate window, not a separate identity. An agent operating in your authenticated profile can do anything you can do, and the security boundary you get is that you can watch it. Whether that is enough depends entirely on what you are logged into.
Worth noting what is not there: no benchmark numbers, no success rates on any web agent task suite, nothing to compare against the browser-agent projects publishing scores. For a project moving 1,300 stars a day, the ergonomics are clearly the draw and the evidence has not caught up yet.
← Back to all articles
The architecture is three pieces and one rule. A CLI called bsk with a local daemon, a browser extension talking to that daemon over WebSocket, and a separate Agent Window the agent drives. The rule, in their own words: the agent never talks to the browser directly. It asks the bsk CLI to perform a browser task, the daemon routes it to the extension, the extension runs it in the Agent Window. You keep using your own windows the entire time.
That separation is doing more work than it looks like. Every browser-automation tool built on a fresh headless profile runs face-first into the thing nobody wants to write about: authentication. Your session cookies, your SSO, your device trust, your MFA prompts, the enterprise app that fingerprints the browser and locks the account when a datacenter IP shows up. Solving that properly is a multi-quarter security project. Riding the profile you are already signed into makes it disappear, and the visible separate window is the concession to the obvious objection, which is that an agent now has your live credentials to everything.
That tradeoff is real and worth stating without spin. The isolation here is a separate window, not a separate identity. An agent operating in your authenticated profile can do anything you can do, and the security boundary you get is that you can watch it. Whether that is enough depends entirely on what you are logged into.
Worth noting what is not there: no benchmark numbers, no success rates on any web agent task suite, nothing to compare against the browser-agent projects publishing scores. For a project moving 1,300 stars a day, the ergonomics are clearly the draw and the evidence has not caught up yet.
Comments