BrowserSkill lets AI agents drive your already-logged-in browser

Browser automation rarely fails at clicking buttons or filling forms — it fails at login. That is the problem BrowserSkill targets. According to a post on dev.to, the project is MIT-licensed, attributed to Tencent, and listed at around 1.8k GitHub stars; instead of launching a fresh browser for an AI agent, it lets the agent work inside the browser a person already uses, with its existing sessions, cookies, and accumulated site trust.

How it works

The dev.to write-up describes two local components: a CLI and daemon called bsk, and a browser extension. With both installed, agent tools such as Cursor, Claude Code, Codex, and WorkBuddy can drive the real browser through the bsk command. Browser tasks run in a separate, visible Agent window, so the agent does not disturb the human's own tabs and its actions can be watched rather than hidden.

Three behaviours stand out in the write-up:

• Login state is reused, so no throwaway test accounts are needed.
• The agent gets its own visible window rather than an invisible context.
• When a task runs into a captcha, a login prompt, or a confirmation dialog, the agent stops, asks the human to take over, and then continues.

Why login is the hard part

The post argues that authentication, not navigation, is where automated browsing breaks down. Sites lean on captchas, SMS codes, QR scans, device fingerprinting, and risk engines built to block non-human traffic. Each common workaround carries a cost, the post notes: dedicated test accounts can attract stricter risk checks, copied cookies expire and break, and headless browsers present fingerprints that get flagged quickly.

BrowserSkill's response is to sidestep the problem entirely. A device with months of ordinary browsing history and a valid session succeeds far more often than a newly created environment, the post claims, so the tool attaches to that trusted environment rather than fabricating one.

The difference from Playwright and Puppeteer

Headless frameworks such as Playwright and Puppeteer spin up new browser instances: new fingerprints, new cookies, no login state. From an anti-bot system's perspective, that combination looks suspicious. BrowserSkill instead attaches to an existing instance whose fingerprints and sessions are long-established. The post presents the two approaches as complementary — headless browsers for scraping public data, BrowserSkill for the steps that require being logged in.

Security trade-offs

Reusing a real, authenticated session raises the stakes when something goes wrong. The design described is intentionally cautious: an agent must explicitly borrow a tab, return it when finished, and leave everything else alone, and it defers sensitive steps to the human. Even so, the post recommends close supervision whenever the agent touches accounts involving money, privacy, or public posting, and characterises the tool as supervised rather than fully autonomous.

It is also worth noting that all of the above comes from a single dev.to post rather than official documentation or independent testing, so specifics such as the supported agent list and star count should be checked against the repository itself.

Why it matters

Login is the practical wall between AI agents and most of the web that actually matters — email, dashboards, banking, internal tools. If BrowserSkill works as described, it changes the economics of agent-driven browsing: rather than building anti-detection infrastructure, an agent rides on trust a human user has already earned. That also reframes the safety question, because the same trusted session that makes tasks succeed makes mistakes more consequential — which is exactly why the visible window and human-takeover design matter. For anyone building agents that need authenticated access, this is a pattern worth watching closely.