Build1 publisher2 min readPublished
Tencent's BrowserSkill runs the agent in a second window on your logged-in profile
The open-source tool routes agent commands through a local daemon into an extension running inside your real browser profile, so every login that profile holds is in reach of whatever agent calls it.
The Engineer · Build desk
What happened
- Tencent has published BrowserSkill, an open-source tool that connects nine named agent harnesses, among them Cursor, Claude Code and Codex, to a browser the user is already logged into.
- The runtime is two local pieces: a command-line tool called bsk that runs a small local daemon, and a browser extension, with nothing routed through remote servers.
- A request travels from the agent's shell call to the daemon over local IPC, then to the extension over a WebSocket on 127.0.0.1, which acts inside a dedicated, visible Agent Window.
- A tab the user already has open is off limits unless the agent borrows it explicitly, and it has to return that tab when the task is finished.
- The recommended install is a single line handed to the agent pointing at AGENT_INSTALL.md in the repository, after which the agent installs the CLI and walks the user through loading the extension.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- capability A coding agent can finish work on internal dashboards and admin panels without anyone minting a service account or provisioning a test login for it.
- exposure Whoever controls the content of a page the agent opens is interacting with a browser that holds the operator's live sessions for every other site in that profile.
- constraint Since no part of the path goes through a vendor service, any audit trail of what the agent browsed on your behalf has to be built and kept locally.
- precedent Distribution by instruction URL, where the setup document is fetched and executed by the agent itself, becomes a normal way to ship developer tooling.
The extension that drives the Agent Window runs inside your real browser profile, and that is what makes the whole thing work: the agent reaches sites you are signed into with no credential handoff and no separate test accounts [6]. One profile has one session store. The agent's window and your windows present that profile's cookies to the same origins [16].
That sets the scope of every task. Attach the profile and each account in it is reachable for as long as the daemon runs, and scoping down means logging out of accounts you use. The dev.to write-up describes the problem the project set out to solve this way: "Your email, your internal dashboards, your admin panels, all of it sits behind a login the agent does not have" [13].
The agent invokes bsk as a shell command [4], and the project's compatibility claim is exactly that: anything able to call a shell can call bsk, with no binding to a particular model, framework or harness [5]. So the gate on authenticated browsing is whichever gate you already keep on shell commands. To that approval logic a bsk call is a command line like any other, and a harness set to auto-approve commands auto-approves browsing as you.
There is a designed stop for the things a program cannot pass. On a captcha, a login screen or a confirmation dialog the agent hands control back, waits, then continues, and the write-up calls this configurable down to the last switch [8]. The write-up does not list the switches.
The macOS and Linux install pipes install.sh into sh and lands bsk in ~/.local/bin, with PATH read from BSK_INSTALL_DIR when it is set [10]. Windows does the same through irm and iex, into the same directory [11].
Underneath all of it is a claim about where agents actually stall. The write-up's version is that the agent can write code, run shell commands and read files, and hits a wall the moment a task touches a website needing your account [12]. Nine harnesses are listed as connecting through the same path [15]. That is a claim about shell access, and checking it takes a minute. The framing claim takes longer: for the login wall to be your binding constraint too, the tasks you abandoned have to be ones a logged-in session would have finished, not ones that failed on the page.
What to watch
- Whether the loopback WebSocket between the bsk daemon and the extension authenticates its caller, and what a second local process can send it.
- The configuration surface for the human-takeover behaviour.
- Whether any of the nine listed harnesses treats a bsk call as more than an ordinary shell command in its approval prompt.