anti-detect-browser-skills: Agent Skills for Driving AntiBrow Profiles

What anti-detect-browser-skills actually installs

This repository does not contain a browser. It contains Agent Skills: instruction packages that an agent reads and then acts on. The README points at agentskills.io for the format and says the skills teach an agent how to launch and manage AntiBrow browsers. The top-level layout confirms the split: four skill directories (anti-detect-browser, browser-mcp-agent, multi-account-isolation, multi-account-scraping) plus a .claude-plugin directory for plugin packaging, a LICENSE, and the README.

The audience is therefore narrow and specific. You need an agent that supports the skills CLI or Claude Code plugins, and you need AntiBrow itself, which is a separate product with its own SDKs. The four skills split by intent. multi-account-isolation is for verifying that profiles are genuinely separate. anti-detect-browser is for writing scripts against the SDK. browser-mcp-agent is for letting the model drive the browser through tool calls with no code. multi-account-scraping is for pulling data from named sites where each account runs in its own profile.

If what you want is a browser binary, this repository is the wrong download. If what you want is a repeatable way to tell an agent how your profiles should be launched and checked, that is exactly what it is.

How the skills split work between SDK scripting and MCP tool calls

The README describes two paths to the same browser. In the SDK path, your code imports a client, constructs it with an API key, and calls launch with a profile name; the returned object exposes a Playwright page. In the MCP path, the agent calls tools and the browser is launched for it. Both paths reach the same profile store.

The claimed differentiator is where the fingerprint is answered. The README states that AntiBrow ships a modified Chromium kernel and that canvas, WebGL, WebGPU, audio, fonts, navigator, screen, DOMRect and timezone are answered inside C++ and Blink. The consequence it draws is that there is no injected script for a detector to find, that Web Workers return the same values as the main thread, and that the TLS ClientHello and HTTP/2-3 behaviour come from a genuine Chrome build. Those are claims about the browser, not about this repository, and they are the kind of claim you should verify with the tools the README itself names: CreepJS, whoer.net, browserleaks.com/canvas, pixelscan.net, or npx liarjs.

Identity is packaged per profile. The README says each profile gets one coherent persona sampled from one real machine, across 30+ categories and 500+ parameters, frozen at creation and replayed on later launches. It also says timezone, locale and WebRTC identity follow the proxy, with the exit IP resolved through the proxy before launch. The design argument is that independently randomized values contradict each other, and a real device's do not.

Installing the skills and launching a first profile

The README gives two install routes. The recommended one is the Claude Code plugin, which installs all four skills together and keeps them updatable through /plugin update. Run these two commands inside Claude Code.

/plugin marketplace add antibrow/anti-detect-browser-skills
/plugin install anti-detect-browser-skills@antibrow

If you want one skill rather than four, the README shows the skills CLI. This example installs only the isolation self-check, which is the one to start with if your question is whether your existing setup holds.

npx skills add https://github.com/antibrow/anti-detect-browser-skills --skill multi-account-isolation

The README also lists --all for every skill and the four individual skill names: anti-detect-browser, browser-mcp-agent, multi-account-isolation, multi-account-scraping. As an alternative to the CLI, it says you can add the repo URL in Claude Code settings under Skills and pick which ones to install.

The skills are instructions, so a first real use means installing the SDK the instructions will drive. The README pins versions in its install lines: npm anti-detect-browser@2.8.0 with playwright-core on Node 18 or later, or pip antibrow==0.9.0 on Python 3.9 to 3.13.

npm install anti-detect-browser@2.8.0 playwright-core   # Node >= 18; pin the version
pip install antibrow==0.9.0                             # Python 3.9 - 3.13

The README's own minimal launch example reads the API key from an environment variable named ANTI_DETECT_BROWSER_KEY and launches a profile by name. The TypeScript form returns a page and a browser.

const ab = new AntiDetectBrowser({ key: process.env.ANTI_DETECT_BROWSER_KEY })
const { page, browser } = await ab.launch({ profile: 'shopper-01' })

The Python form is shorter and, per the README, reaches the same profile with the same fingerprint.

from antibrow import launch
browser = launch(profile="shopper-01")   # same profile, same fingerprint
page = browser.new_page()

One detail worth knowing before you plan a mixed-language pipeline: both SDKs share the directory ~/.anti-detect-browser/, so a profile created from Node is launchable from Python and from the desktop app with the identical identity. The README also states that playwright install is never needed, because AntiBrow drives its own kernel.

The isolation checks are the part that earns its place

The most useful skill here is the least glamorous one. multi-account-isolation is described as ten concrete checks in the skills list and eleven in the later section, which is a discrepancy in the README itself and worth noting rather than smoothing over. The checks it names are specific: timezone against exit IP, WebRTC candidates, canvas stability across relaunches, worker versus main thread, one GPU across three interfaces, and duplicate personas or addresses across a fleet.

That framing is honest about the failure mode people actually hit. An anti-detect setup rarely fails because a single parameter is wrong; it fails because two profiles share something they should not, or because a value drifts between launches. Canvas stability across relaunches and duplicate personas across a fleet are exactly the checks that catch a broken profile store rather than a broken fingerprint. The README also says the skill covers which detection suites to run, what the runtime does with your credentials, and which layers browser isolation cannot cover at all. That last item is the one to read first if you are evaluating the product, because it is the vendor telling you where the boundary is.

The README points at npx liarjs from liarjs.dev as roughly 40 open-source cross-layer consistency rules you can run in CI. Running those rules in CI is a more defensible position than trusting a dashboard, because it turns isolation into a test that fails a build.

Where this is the wrong tool: platform gaps and the browser you still have to buy

The first limitation is structural. This repository is skills, and skills do nothing without AntiBrow. Nothing in the README suggests the browser is included, free, or open source; the repository's MIT licence covers the instruction files, and the SDK packages are published separately on npm and PyPI. If your search was for a free anti-detect browser, this is not one, and the repository does not claim to be.

The platform table is the second constraint, and it is unusually candid. Windows 10 and 11 x64, macOS 12 or later on both Apple Silicon and Intel, Linux x64 with glibc, and Linux arm64 with glibc are listed as supported, the arm64 build being a separate kernel auto-selected from the CPU. Docker is supported for linux/amd64 and linux/arm64, described as headful under Xvfb. Linux musl, which means Alpine, is listed as not yet. There is no Android row and no iOS row. If your deployment target is Alpine containers or a phone, the table answers you before you install anything.

The third is the one the README states most plainly: the skills are for identities you own or are authorized to operate, and it links to an Acceptable use section. Multi-account work against sites you do not control, or against a site whose terms forbid it, is outside that framing regardless of what the fingerprint does. That is a product boundary, not a technical one, and it is the boundary a team should settle before writing any of the scripts the anti-detect-browser skill would help them write.

How it differs from a stealth plugin like puppeteer-stealth

The README draws its own comparison and it is a fair one to restate. Stealth tooling patches JavaScript from the outside: it overrides a getter, shims navigator, monkey-patches toString. The repository's argument is that anti-bot vendors have been fingerprinting those patches for years, so the patch itself is the tell.

The difference in approach is where the answer is produced. A stealth plugin answers in JavaScript, on the main thread, after the page has begun executing. AntiBrow, per the README, answers in C++ and Blink inside a modified Chromium kernel. Two consequences follow that a JavaScript patch cannot reproduce. Web Workers, which detectors re-read precisely because partial overrides only touch the main thread, return what the main thread returns. And the TLS ClientHello and HTTP/2-3 behaviour belong to a real Chrome build, a layer no JavaScript running in the page can reach.

That is the honest version of the trade-off. A stealth plugin is a package you add to an existing Playwright or Puppeteer install and it costs you nothing but a dependency. This is a separate browser with a separate kernel, a separate profile store under ~/.anti-detect-browser/, and a separate SDK to pin. You are trading a dependency for an install and a vendor. Whether that trade is worth it depends on whether the layer the plugin cannot reach is the layer that is currently flagging you, and the repository's own suggested way to find out is to run CreepJS or npx liarjs against both.

Maintenance, version pinning and what the MIT licence does not cover

The repository is not archived and the last push was on 2026-08-28, which is recent. There are no releases retrieved, so there is no changelog to read and no tagged version of the skills to pin against. Upgrades for the plugin route go through /plugin update, which the README names as the reason to prefer the plugin install.

The SDKs are a different matter, and the README pins them explicitly: anti-detect-browser@2.8.0 on npm and antibrow==0.9.0 on PyPI. That pinning is the upgrade cost you should plan for. Because both SDKs share the profile directory ~/.anti-detect-browser/, a profile created under one version is read by the other, so an SDK upgrade is not scoped to one language in a mixed pipeline. The README does not document rollback behaviour for a profile store after an upgrade, and it does not say whether a profile created by an older kernel remains launchable after a kernel update, even though kernel updates are listed among the topics the anti-detect-browser skill covers.

On licensing: the repository carries MIT. That covers the skill files in this repository. It does not cover AntiBrow itself, and it does not cover the npm or PyPI SDK packages, which carry their own terms. If you need to know whether the browser can be redistributed inside a product, or whether the kernel can be shipped to customers, the MIT file here is not the document that answers it. That is a question for the vendor, and this is not legal advice.

Editorial conclusion

Adopt these skills if you already run AntiBrow and want an agent to write scripts or drive profiles over MCP, and start with multi-account-isolation if your question is whether profiles are truly separate. Do not adopt them expecting a free or standalone anti-detect browser, or Android support, or a musl Linux build: the README lists none of those. Before relying on it, verify that your agent supports the skills format, that your platform appears in the supported table, and that your intended use fits the repository's acceptable-use section.

Frequently asked questions

Official sources

1. antibrow/anti-detect-browser-skills on GitHub
2. Issues
3. License: MIT
4. README