Tencent Open-Sources BrowserSkill: Agents Borrow Your Real, Logged-In Browser

Most AI agent browser tools hand the agent a blank slate: a fresh, logged-out browser instance with no cookies, no session, nothing. That's safe, but it means every task that touches a site you're signed into requires a separate login flow, a test account, or manual credential handling before the agent can do anything useful. On September 16, 2026, Tencent AI announced it had open-sourced a different approach: BrowserSkill, a CLI that lets an agent borrow a tab from the browser you're already using — logged in, cookies intact — complete a task, and hand it back.

The launch thread put it plainly: "most tools give the agent a blank browser. We let it borrow a tab from yours, then hand it back." It picked up 63.8K views and a genuinely useful mix of reactions — practical praise for reusing login state, a fair "didn't browser_use already do this?" comparison question, and, most usefully, engineers flagging the real security tradeoff this design makes. All three threads are worth walking through if you're deciding whether to wire this into your own agent harness.

TL;DR: What people are asking

How it actually works, mechanically

BrowserSkill's architecture is deliberately simple and has a clear reason for each layer, per Tencent's own README:

1. The agent never talks to the browser directly. It calls the local bsk CLI.
2. The CLI talks to a local daemon, which is the process that actually tracks sessions, tabs, and permissions.
3. The daemon routes the request to a browser extension installed in your Chrome or Edge.
4. The extension executes the task in a separate, visible "Agent Window" — not your active tab — so you can keep working in your own browser while the agent works in its borrowed one.

DeepSeek Harness users get a dedicated plugin (@wxg-prc-cpg/browser-skill-dsh-plugin) that exposes native browser_* tools and a live view of agent browser sessions in its web UI, but under the hood it's calling the same bsk CLI on the agent's behalf — there's no separate protocol.

The permission model: what actually gates the agent

This is the part of the launch that drew the most substantive engagement, and it's worth being precise about because the details changed meaningfully as of version 0.3.0. Two independent toggles live in the browser extension's settings — not in a CLI flag, not in an environment variable — and both default to on:

The notable design decision, called out explicitly in Tencent's own docs and echoed approvingly in the launch thread's replies: as of 0.3.0, the legacy --unattended flag, tab borrow --no-confirm, and BSK_REQUEST_HELP=off are deprecated and can no longer override these settings. Earlier versions let a command-line flag silently disable confirmation; now that decision has to be made in the browser UI itself, which closes an obvious path for a compromised or malicious script to talk its way around the safeguard by just passing a flag.

The comparison question worth taking seriously: is this just browser_use?

One reply in the launch thread asked directly whether BrowserSkill is a reskin of browser_use, an existing popular open-source project for AI-driven browser control. The honest answer is that the goal — letting an LLM-driven agent control a real browser — isn't new, and browser_use, Playwright-based agent wrappers, and Anthropic's own computer-use browser skills all cover overlapping ground. What's specifically different about BrowserSkill's design is narrower than "AI controls a browser":

• It's a CLI, not a Python library or framework binding. Any agent that can run a shell command can use it — this is the same "shell is the API" philosophy behind tools like Firecrawl's keyless agent search, and it's why Tencent can credibly list nine-plus unrelated agent harnesses as compatible without maintaining nine separate integrations.
• It borrows your existing browser rather than launching a new one. Login state, extensions, and cookies you already have are simply present, rather than requiring a parallel authenticated profile the agent manages independently.
• The permission boundary is enforced in the extension, on your machine, not as a parameter passed at task-start time that the calling code (or an injected instruction) could adjust.

Whether that's a meaningfully better architecture than browser_use for a given workflow depends on whether you want an agent working through your real identity or a sandboxed one — which is exactly the tradeoff the next section covers.

The security tradeoff nobody should skip

Several engineers in the launch replies raised the same concern from different angles, and it deserves to be stated plainly rather than buried in a FAQ: reusing your real login state is also reusing your real attack surface. If an agent visits a page containing a prompt injection — hidden text instructing it to take an unintended action — and that agent is operating through a tab where you're already authenticated to your email, your bank, or your company's internal tools, a successful injection isn't limited to a sandboxed test account. It's your actual session.

BrowserSkill's confirmation-and-handback design is a real mitigation, not decoration — it stops an agent from silently opening arbitrary tabs to sites you never asked it to visit, and captchas/logins genuinely can't be automated around. But as one commenter in the thread put it in more precise terms than "be careful": what matters is putting tab borrowing, login state, confirmation dialogs, prompt-injection defenses, and audit logging into a single replayable record, so convenience and control aren't a one-time tradeoff made at install time but something a team can actually verify after the fact. If you're deploying this for anything beyond solo, low-stakes use, treat that audit trail as a requirement to build around BrowserSkill, not something the tool hands you automatically — the same discipline covered in explainx.ai's guide to securing agent skills.

Setup, in practice

For any shell-capable agent (Cursor, Claude Code, Codex, and the rest), installation is a single instruction handed to the agent itself:

Set up browser-skill on this machine by following https://raw.githubusercontent.com/Tencent/BrowserSkill/main/AGENT_INSTALL.md

The agent installs the CLI and skill, then walks you through loading the browser extension. A first-use check is simple: ask the agent to open a URL and summarize the page; if BrowserSkill is wired up correctly, that's a full round trip through the CLI, daemon, extension, and Agent Window. For harnesses using MCP-style skill invocation or slash commands, Tencent documents a /browser-skill command form as well, though the underlying mechanism is the CLI either way, not an MCP server.

Where this fits and where it doesn't

BrowserSkill is a good fit for personal or small-team workflows where an agent needs to act on sites you're already signed into — checking a dashboard, filling a form on an internal tool, pulling data from a service without API access — and where you're comfortable being the human in the loop for anything sensitive. It's a weaker fit for unattended, high-volume automation at scale, since the entire design assumes a human is available to approve borrows and clear captchas; disabling those safeguards for throughput defeats the point of the tool and reopens the exact risk its defaults exist to prevent. If your workload is genuinely unattended and high-volume, a sandboxed, credential-scoped automation approach — logged into dedicated service accounts rather than your personal session — remains the more defensible architecture, even if it means more setup.

The honest limits, as of this release

• Chrome and Edge only, officially — other Chromium-based browsers are "expected to work," not tested and guaranteed; Firefox support is planned but unavailable.
• Confirmation gates the borrow, not every in-page action — once a tab is borrowed and a task is running, the agent operates with the permissions of your logged-in session for the duration of that task.
• Mixed-version installations retain legacy behavior — an older CLI paired with a newer extension, or vice versa, can behave differently than the current documented settings describe, which is worth checking with bsk status and bsk doctor before relying on the confirmation guarantees in a team setting.
• No independent third-party security audit publicized at launch — the confirmation and handback design is Tencent's own, and the prompt-injection exposure it creates is inherent to the "borrow a real session" model regardless of how well the confirmation UI is built.

Related reading

• Anthropic's Claude Platform: computer use, browser skills, and Files API reach GA
• Browserbase Skills for Claude Code browsing
• Claude in Chrome browser extension: a guide to using it safely
• Securing your AI agent skill registry
• Firecrawl: free, keyless agent web search and scraping
• What is MCP? Model Context Protocol architecture guide
• Agent harness engineering: Terminal-Bench and LangChain
• Official: BrowserSkill on GitHub · AGENT_INSTALL.md

Feature details, permission model, and version notes in this piece reflect Tencent's own BrowserSkill README and changelog as of the September 16, 2026 announcement (bsk CLI 0.2.1, with 0.3.0 in preparation). Security characteristics of any agent-controlled browser tool depend heavily on your own configuration and threat model — verify the current defaults with bsk status and bsk doctor before relying on this in a shared or production environment.