browser-act/skills: a CLI that gives AI agents a browser, an index for clicking, and a human on standby
Browser automation CLI built for AI agents. Break through anti-bot walls, hand off to humans across platforms when stuck. Parallel multi-task execution, independent multi-session operation, isolated multi-account browsing.
At a glance
- What is it?
- BrowserAct Skills is an MIT-licensed Python CLI plus agent Skill that drives real Chrome sessions for scraping and account workflows, with anti-bot handling, indexed interaction, and a remote-assist handoff. The cloud half of the product is the part you pay for; the local half is the part you install.
- Who is it for?
- Adopt browser-act/skills if you are building agent workflows that need a real logged-in browser, indexed click targets instead of DOM parsing, and a defined escape hatch when the agent stalls. Do not adopt it if you need a self-contained scraper with no vendor dependency, since the README's own framing points at the cloud product for lower operating cost and the local path exists to serve agent integration.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 22 days ago.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap this fills: agents that can reason about a page but cannot act on it
An LLM that can read HTML still cannot log into a site, hold a session across steps, or get past a challenge page. The usual workaround is a hand-written Playwright or Selenium script, which puts the automation logic back in human-authored code and out of the agent's reach. BrowserAct Skills takes the opposite position: the agent issues commands, the CLI owns the browser.
The README states the target audience directly. It is for agents and teams doing real-browser automation, web data extraction, and account-based workflows, with local browser control, local Chrome login-state reuse, or direct integration into an existing agent workflow. The compatibility list names Claude Code, Cursor, VS Code, OpenCode, OpenClaw, Codex, and Gemini CLI, with the caveat that it works with any agent that can run a shell command. That list is the real scope statement. If your agent cannot shell out, this is not for you.
The project is Python, MIT-licensed, and last pushed on 2026-08-24. No releases were retrieved, so versioning appears to run through the Skill source path and a `--skill-version` flag rather than tagged artifacts.
Three browser modes and what each one is actually for
The README separates browser handling into three scenarios, and the distinction matters more than the feature list.
The `chrome` mode reuses local Chrome login state, either by importing a profile or attaching over CDP. This is the mode for anything behind a login you already have in your desktop browser. It is also the mode with the most to lose if something goes wrong, since the session carries your real cookies.
Stealth privacy mode is for batch scraping without login. Each session gets a fresh fingerprint and proxy rotation, and the README describes the residue as zero when the session ends. Stealth fixed identity is the third case: a stable fingerprint paired with a stable IP, intended for logged-in accounts and multi-browser parallelism where the account identity has to stay consistent and not be flagged.
The trade-off is explicit in that split. Privacy mode buys you clean separation between runs at the cost of not being able to stay logged in. Fixed identity buys persistence at the cost of pinning a fingerprint and an IP together, which is exactly the coupling that makes an account look like a bot if the pairing drifts.
How the agent actually drives the page: state, indexes, and short commands
The mechanism is an indexed interaction loop rather than DOM parsing. The agent runs `state`, which returns a numbered list of interactive elements, then acts on a number: `click 3`, `input 2 "hi"`. The README's own quick start shows the full cycle.
The commands run against a named session:
browser-act --session my-task browser open <id> https://example.com browser-act --session my-task state browser-act --session my-task click 3 browser-act --session my-task input 2 "hi"
Two design choices sit behind that. First, output format: the README claims an indexed text format that is several times more token-efficient than JSON or HTML. That claim is not benchmarked in the material, so treat it as a design intent rather than a measured figure. Second, semantic memory: every browser carries a `desc` field, and tasks are matched to browsers by meaning rather than by an ID you have to track. Combined with session ownership and explicit naming, the stated goal is that multi-agent operation does not collide.
There is also a zero-config path for the narrow case of pulling a protected page: `browser-act stealth-extract https://example.com`. That is the one command in the README that needs no session, no setup, and no state loop.
Anti-bot handling in three layers, and the human one that matters most
The README describes three progressive layers against blocks. The environment layer covers stealth fingerprint spoofing, TLS rotation, and proxy switching, and claims the vast majority of blocks never trigger. The execution layer adds `solve-captcha` for automatic CAPTCHA solving and `stealth-extract` for protected pages in one command. The third layer is the interesting one: `remote-assist` generates a live URL, a person opens it from any device, takes over the browser, and the agent resumes when they are done.
That third layer is the honest admission in the design. Every anti-bot stack has a ceiling, and rather than pretend otherwise, BrowserAct routes past it to a human. The cross-platform claim is that the handoff link works from any device, which is what makes it usable for an agent running unattended on a server.
What the material does not say is how the handoff is authenticated, how long a generated URL stays live, or what happens to the session if nobody picks it up. Those are the questions to ask before putting this in a pipeline that runs without someone watching.
Concurrency: cross-browser lanes versus sessions inside one browser
The README draws a line between two kinds of parallelism. Cross-browser parallel means independent cookies, fingerprints, and proxies, so a site cannot correlate the runs with each other. Same-browser multi-session means shared login state with independent execution, so tasks do not block one another.
Those are not interchangeable. If you need ten accounts to look like ten different people, you need the cross-browser lane, because sharing a browser means sharing the fingerprint. If you need ten tasks to run against one logged-in account without queueing behind each other, the same-browser lane is the right shape and the cross-browser one is wasted overhead.
The README also states that privacy mode gives a fresh fingerprint and an empty profile per session. That is the cleanest isolation model on offer, and it is also the one that cannot hold a login. Picking a mode is therefore picking which property you are willing to give up.
Install and the first commands to run
The README's install instruction is a prompt, not a shell command. You tell your agent: install browser-act, skill source https://github.com/browser-act/skills/tree/main/browser-act, and verify it works after installation. Installation details live in docs/installation.md, which is not reproduced in the material, so the exact package name and dependency set cannot be confirmed from what is here.
At the start of each session the agent is expected to run `get-skills`, which returns environment state, the browser list, and available commands in a single call. The README gives this example:
browser-act get-skills core --skill-version 2.0.2
That version flag is the upgrade surface. There is no package manager version to pin in the material, so the Skill version is what you track. Note also that the README's quick start uses `browser open <id>`, meaning the agent needs a browser ID from somewhere before the first navigation. The `get-skills` call is presumably where that ID comes from.
One more thing worth flagging: sensitive operations require explicit user approval, and prior approvals do not carry over. The list includes browser create and delete, profile import, proxy changes, and security and privacy toggles. The README states this is enforced at the Skill layer rather than as a configuration toggle, which means you cannot switch it off in a config file.
Where it is the wrong tool, and what to use instead
The clearest limitation is structural rather than technical. The README describes two usage modes, and the cloud mode is pitched on lower operating cost with no agent setup. The local Skills path is framed around local browser control, local Chrome login-state reuse, and integration into your own agent workflow. If what you want is a scraper that runs on your own infrastructure with no external service in the loop, this repository is not that product. The MIT licence covers the code here; it says nothing about the hosted execution, proxies, or CAPTCHA solving that the anti-bot layers depend on.
For the self-hosted case, Playwright is the direct alternative, and the difference is not cosmetic. Playwright gives you a programmatic API where your code selects elements with locators and waits, and nothing is indexed for an LLM to click by number. BrowserAct inverts that: the page is summarised into a numbered list and the agent acts on integers. Playwright also assumes you will handle fingerprinting, proxies, and CAPTCHAs yourself, which is precisely the work BrowserAct claims to absorb.
So the split is honest. Choose Playwright when the automation logic is stable enough to write down and you want no vendor in the path. Choose BrowserAct when the sequence is not known in advance and an LLM is deciding the next step, because that is the case the indexed-state loop was built for.
A second limitation is the confirmation gating itself. It is a safety property, and it is also a friction cost in unattended runs: an agent that needs to create a browser and cannot get approval will stall. The README does not describe a way to pre-authorise a batch of operations, and it says prior approvals do not carry over.
Maintenance, upgrade cost, and the licence boundary
Upgrade cost here is not a dependency bump. The Skill is installed from a repository path, and the version is passed at runtime through `--skill-version`, as in the `get-skills core --skill-version 2.0.2` example. That means an agent's behaviour can shift with the Skill version while the surrounding code stays put, so the version string is worth recording alongside whatever results you get.
There are no retrieved releases, so there is no changelog to read before upgrading. The material also does not describe a deprecation policy for commands like `stealth-extract` or `remote-assist`. If you build on those, you are building on a surface with no stated stability guarantee.
The licence is MIT for this repository. That is permissive for the code you install. It does not extend to browseract.com or to the cloud execution path, and the README routes cloud usage through the product site rather than through anything in this repo. Read the two as separate things: an MIT Skill layer that talks to a commercial service. This is a description of how the pieces are presented, not legal advice on your specific use.
The security-relevant fact to carry forward is that confirmation gating is enforced in the Skill layer, not as a toggle, so it is not something you can relax by editing a config file. If that gating blocks a workflow you need, the workaround has to live in your agent's orchestration, not in BrowserAct's settings.
Editorial conclusion
Adopt browser-act/skills if you are building agent workflows that need a real logged-in browser, indexed click targets instead of DOM parsing, and a defined escape hatch when the agent stalls. Do not adopt it if you need a self-contained scraper with no vendor dependency, since the README's own framing points at the cloud product for lower operating cost and the local path exists to serve agent integration. Verify first that the MIT-licensed Skill layer is separable from the hosted execution and proxy infrastructure, because the licence covers this repository and says nothing about the service behind browser-act.com.
Community notes