dsh-antibrow: a persistent browser identity for DeepSeek Harness agents

The problem is a browser with no memory

Most browser plugins for an agent hand it a fresh Chromium. For reading a public page that is enough. For anything behind a login it fails, and it fails in a way that looks like the agent's fault: the session dies with the process, the fingerprint is a stock automation build, and the traffic leaves from your own machine. Logging in again on every run is itself the signal a site treats as suspicious.

dsh-antibrow is aimed at that second class of work. The README names the cases directly: check a mailbox, watch a dashboard, keep a marketplace account warm. The target reader is someone running a DeepSeek Harness agent that has to be someone across multiple runs, not a one-shot scraper. The unit of identity is a named profile, and the profile is what persists.

Spoofing below the page, not inside it

The browser is AntiBrow, a Chromium fork driven through the standard Playwright API. The important design choice is where the fingerprint is answered. According to the README, the user agent, platform, screen, fonts, canvas, WebGL and audio are answered by the engine itself, before any page script runs. Nothing is injected into the page, so there is no injected script for a detector to find. Plugins that patch from page scripts leave that artifact behind.

The second choice is coherence. Timezone, locale and the reported network profile are derived from the proxy's real exit, because a US IP reporting Shanghai time is a contradiction a page can check in one line. The README's measurement table, taken on a macOS host through a US residential proxy on 2026-08-15 with engine 151, reports whoer.net disguise at 90 percent, creepjs headless and stealth signals at 0 percent, and agreement between the reported platform and the user agent. The missing 10 percent is WebRTC, which had no route to a STUN server on that run. The repository ships the harness under tests/smoke, and the README says it fails loudly rather than printing a number nobody checks. That is the right place to put a claim like this: in a test you can rerun, not in a marketing table.

Installing dsh-antibrow and launching a first profile

The plugin is installed through the harness itself, with a profile name of your choosing. The README gives a three-line sequence: add the plugin, export the key, start the harness.

dsh plugin --profile <name> add dsh-antibrow
export ANTI_DETECT_BROWSER_KEY=<key>
dsh --profile <name>

The first two commands register the plugin against that harness profile and put the AntiBrow key in the environment. The third starts the harness with the plugin active.

Once the agent is running, the tool surface is exposed under `mcp__antibrow__*` and is reachable from Code Mode as ordinary async calls. `launch_browser` takes a profile name and creates it on first use, so the first call is also the profile creation. For automation work the README recommends passing `temporary: true`: those profiles stay local-only and out of the desktop app's list, while still persisting on disk.

An Android profile is the same call with one extra argument. The README shows the shape:

{ "profile": "shop-mobile", "deviceType": "android", "temporary": true }

Three captured Android devices ship inside the package, so a free-tier agent can create one with no network round trip. Expect the first `launch_browser` of a fresh install to be slow: the engine downloads on first launch, 190 to 320 MB depending on platform, into a shared cache directory. Later launches do not pay that cost. If you need the phone, the engine must be 151 or newer; the README states that launch fails rather than quietly handing you a desktop browser that claims to be a phone.

One browser at a time on a free key

The concurrency limit is the constraint to read before designing anything. On a free key the plugin allows one browser at a time, and the limit is carried by the license and counted per machine, across every application using the same engine. That last clause matters: another tool on the same host using AntiBrow counts against the same budget. Fan an agent out into parallel sessions only on a plan whose limit covers them, or the extra launches are refused.

The second failure mode is identity sharing. A profile is a real identity, and two agents driving one profile at once is the same mistake as two people sharing one browser: last one to close wins. The README's instruction is to give each agent its own profile. There is no locking described, so this is a discipline the operator has to keep, not something the plugin enforces.

The plugin is also the wrong tool when the job is a single public page read. You pay for an engine download, a key, and a profile lifecycle to get a browser that behaves like a browser. A plain Playwright setup is lighter for that case, and the README's own comparison table concedes the point: a fresh Chromium is fine for reading a public page.

How it compares to a plain Playwright plugin

The alternative the README positions against is a plain Playwright browser plugin, which hands the agent a new browser every run. The difference is not speed or API surface, both of which are Playwright's. It is state. A plain plugin has one data directory to share and starts from nothing, so identity between runs does not exist, logins are gone when the process ends, and egress is your own IP.

dsh-antibrow keeps one persistent profile per name, stores WebAuthn credentials with the profile rather than in the machine's keychain, and can route egress through a residential proxy with timezone, language and reported connection following its exit. Tabs restore the last session so the agent resumes where it stopped. The trade is operational weight: a key, a per-machine concurrency limit, and a large engine download on first use. If your agent never logs in and never needs to look like a specific machine, the plain plugin is the smaller commitment.

Profiles, licensing and what maintenance costs

Profiles are unlimited on the free tier. The README is explicit that they live on your disk rather than on a plan, and that creating one costs nothing. The paid parts are syncing profiles between machines and the managed residential proxies. The Android device type is fixed when the profile is created and never drifts, so a profile that was a phone stays that phone.

Portability cuts both ways. A profile can be exported as a file and imported on another machine, and an unsynced profile is still there in the desktop app for a human to open and finish by hand. The same profile runs on Windows, macOS, and Linux on both x86_64 and arm64.

The package is MIT licensed, and package.json ships only `cordis.patch.yml`, `cordis.patch.local.yml` and the README, so the plugin itself is a thin configuration layer over the `anti-detect-browser` CLI. The browser engine and the proxy service are separate products with their own terms; the MIT grant covers this repository, not them. The bundle inserts one row, `mcp-antibrow`, configuring the harness's MCP client against that CLI, and the README says you can override it from your profile's own `cordis.patch.yml` by targeting that id, with a patch replacing the existing row. The repository's last push was on 2026-09-12 and it is not archived.

Editorial conclusion

Adopt dsh-antibrow if your agent has to hold an account across runs: log in once, keep the cookies and passkeys, and come back to the same browser. Do not adopt it for parallel fan-out on a free key, because the concurrency limit is counted per machine across every application using the same engine, and extra launches are refused. Before relying on it, check that the first launch can pay the 190-320 MB engine download into the shared cache, and confirm your engine build is 151 or newer if you need the Android device type.

Frequently asked questions

Official sources

1. antibrow/dsh-antibrow on GitHub
2. Issues
3. License: MIT
4. Project website
5. README