# ShardX Launcher: an MIT-licensed anti-detect Chromium launcher with a local API and SDKs

> ShardX Launcher manages isolated browser identities on a patched Chromium build and exposes them through a desktop UI, a local HTTP API, an MCP server and Python, Node and Rust SDKs. The engine-level spoofing is the interesting part; the proxy dependency is the part to check before you commit.

**ProxyShard/ShardBrowser** — Free, open-source anti-detect browser launcher for web scraping and multi-accounting. By the ProxyShard team. Engine-level fingerprint spoofing in Chromium 148 (WebGL / WebGPU / Client Hints / fonts / TLS), 170+ device profiles bundled, stable QUIC + WebRTC over SOCKS5.

- Repository: https://github.com/ProxyShard/ShardBrowser
- Stars: 1,154 · Forks: 131
- Language: TypeScript
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/proxyshard-shardbrowser

## The problem ShardX Launcher solves, and for whom

Running many browser identities from one machine usually breaks in the same place. Cookies and storage can be separated with a profile directory, but the signals the browser leaks about the machine underneath stay identical across every profile, so accounts that should look unrelated end up sharing a GPU string, a font list or a TLS handshake. ShardX Launcher attacks that specific gap. It manages a set of profiles, each one holding a complete device identity: GPU, screen, fonts, audio settings, timezone, locale, WebGL and WebGPU capabilities, TLS ClientHello, UA-CH, WebRTC policy, geolocation and cookies. The README states the signals within a profile are kept consistent with one another, which is the harder half of the problem.

The intended users are scrapers and multi-account operators who drive browsers programmatically. That is visible in the shape of the project rather than in any marketing line: there is a local HTTP API, an MCP server, and standalone Python, Node and Rust SDKs that ship the browser engine and run without the desktop UI, described as intended for scrapers, CI jobs and servers. Someone who wants a browser to click around in manually is not the target. Someone who wants to launch two hundred profiles from a queue is.

## Engine-level spoofing instead of JavaScript injection

The design decision that separates ShardX from the common approach is where the fingerprint values are applied. Most stealth tooling patches the page after it loads, overriding navigator properties and WebGL getters from JavaScript. That works until the page inspects a worker, an iframe, or the developer tools protocol, where the patched values and the real ones can diverge. ShardX applies changes inside Chromium's C++ engine, and the README names Blink, V8 and the network stack as the layers involved. The stated consequence is that the same values are visible in frames, workers, developer tools and headless sessions.

That claim is testable in principle, and the README points at verification results and test pages, though the excerpt of that table is cut off before the results appear. Treat the claim as the project's own until you reproduce it. The networking side is the other half. QUIC and WebRTC both ride on UDP, and SOCKS5 only carries UDP through the relay extension in RFC 1928 section 7. ShardX runs QUIC over the proxy UDP relay and follows the configured proxy policy for WebRTC so the host IP is not exposed. The README is explicit that other proxy providers can be used, but full QUIC and WebRTC operation requires SOCKS5 UDP relay support. That sentence is the load-bearing constraint of the whole project.

## Four control surfaces over one local state

The launcher exposes the same profiles through four interfaces, and the README notes they all use the same local state, so there is no synchronization step between them. The desktop UI is the workspace for profiles, proxies, cookies and the fingerprint editor. The local HTTP API listens on 127.0.0.1:40325 with Bearer JWT authentication, and lets you create, start and stop profiles from any language before obtaining a CDP endpoint. The MCP server connects ShardX to Claude Desktop, Cursor and other MCP clients for natural-language profile orchestration through the HTTP API and CDP. The standalone SDKs are Python, Node and Rust libraries that ship the engine and skip the desktop UI entirely.

The repository layout matches that description. There are mcp/, sdks/, src-tauri/, src/, ui-kit/ and openapi.yaml at the top level, and package.json shows a Tauri 2 shell with React 19, Vite and a local UI kit dependency referenced as file:./ui-kit. The launcher itself is TypeScript on the front end with a Rust sidecar through Tauri, which is a reasonable split for a desktop app that has to spawn and supervise browser processes. The openapi.yaml file is the contract for the HTTP API; if you plan to drive ShardX from another language, that file is the first thing to read, not the SDK docs.

## Installing the launcher and launching a first profile

The README's quick start section is referenced in the header navigation as Install, but the excerpt does not include its contents, so the steps below come from what the repository does document: the package scripts, the API port, and the SDK entry points. For the desktop launcher, the repository is a Vite and Tauri project, and the build script runs the UI kit build first through a prebuild hook.

```bash
npm install
npm run build
```

The prebuild step runs the build:ui-kit script, which installs the ui-kit directory with npm ci and then builds the library, so the first build takes longer than later ones. After that, the tauri script in package.json is the entry point for the desktop shell. If you only want the browser engine without the UI, the README points at the standalone SDKs instead, published as shardx on PyPI, @proxyshard/shardx on npm and shardx on crates.io.

```bash
pip install shardx
```

Once the launcher is running, the local HTTP API is the surface most automation will use. It listens on 127.0.0.1:40325 and requires a Bearer JWT, so the first call is an authenticated request to create a profile, followed by a start call that returns a CDP endpoint. The README does not print the exact HTTP paths in the excerpt, so read openapi.yaml in the repository root for the route names and payload shapes rather than guessing them. What you should see from a working API is a JSON response rather than a connection refused error. If the port is closed, the launcher is not running. If the token is wrong, the request is rejected. Both failures are unambiguous, which is more than can be said for a lot of local control planes.

## Where ShardX Launcher is the wrong tool

The proxy requirement is the sharpest limitation and it is stated plainly. Full QUIC and WebRTC operation requires SOCKS5 UDP relay support. If your proxies are HTTP-only, or your SOCKS5 provider does not carry UDP, you lose the QUIC and WebRTC behaviour that the project treats as a core capability, and you are left with the fingerprint spoofing and the profile management. That is still useful, but it is a different product from the one the README describes, and the README does not document a fallback mode for it.

The second limitation is the patched browser itself. ShardX ships a modified Chromium build, and the README mentions Chromium 152 in the header while the repository description mentions Chromium 148. Those two numbers disagree, and the discrepancy is not explained anywhere in the project's own text. Whichever is current, a patched engine has to be rebased onto upstream Chromium releases to pick up security fixes, and nothing in the README describes that cadence or a rollback path. The README does not document rollback. If you are running this against untrusted pages, you are trusting the maintainers' rebase schedule, and you should check the release notes for the engine version before each upgrade.

Third, this is the wrong tool for a single account on a normal machine. The profile model, the proxy binding and the API all assume you are running many identities or driving browsers from code. For one browser session, a stock Chromium with a clean profile directory is less machinery for the same result.

## How it differs from Camoufox

Camoufox is the comparison people reach for, and the two take different routes to the same goal. Camoufox is a Firefox-based build with fingerprint modifications applied to that engine. ShardX is Chromium-based and patches Blink, V8 and the network stack. The practical difference is the ecosystem around the engine: a Chromium build keeps the Chrome DevTools Protocol, which is what ShardX hands back when you start a profile, so existing Puppeteer and Playwright code that speaks CDP has a shorter path to working. A Firefox-derived build does not give you CDP in the same form.

The other difference is the control plane. Camoufox is a browser build you launch; ShardX is a launcher that manages profiles, proxies and cookies, plus a local API, an MCP server and SDKs. If you already have your own profile management, ShardX's launcher layer is redundant weight, and you would be better served by a browser build alone. If you do not have that layer, the launcher is the part that saves you from writing it. The trade-off runs the other way too: a launcher that owns profiles, cookies and proxies is a larger surface to audit than a browser binary.

## Licence, release cadence and what upgrades cost

ShardX Launcher is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is the permissive end of the spectrum, and it means you can embed the SDKs in a commercial scraping pipeline without a copyleft obligation on your own code. It does not tell you anything about the patched Chromium binary's own licensing, and the README does not address that question. If you redistribute the browser build itself rather than just calling the API, that is the point to check with someone qualified, because Chromium's licensing is not the same as the launcher's.

The release history shows v2.0.0 on 2026-09-01 and v2.0.1 on 2026-09-03, with v0.1.10 back on 2026-06-21. Two releases inside three days suggests active work around the 2.0 line, and the last push to the repository was on 2026-09-03. The package.json version is 2.0.3, which is ahead of the latest tagged release, so the main branch carries changes that are not in a release yet. That matters for upgrades: if you pin to a tagged release you get tested code, and if you build from main you get the 2.0.3 state. The upgrade cost is dominated by the engine version, not the launcher code. Every time the patched Chromium is rebased, your fingerprint assumptions and any test suite that asserts on browser version strings need to be rechecked.

## Conclusion

Adopt ShardX if you need many isolated identities driven from code and you already have SOCKS5 proxies with UDP relay, since that is what the QUIC and WebRTC path assumes. Do not adopt it if you want a single stealth browser for one account, or if you cannot supply SOCKS5 UDP relay, because the README states full QUIC and WebRTC operation requires it. Before you commit, verify two things: that your proxy provider actually relays UDP, and that the SDK release you install matches the patched Chromium version the launcher ships.

## FAQ

### Is ShardX Launcher free to use?

Yes. The repository is MIT licensed and the README states ShardX is free to use. The MIT terms allow commercial use and modification as long as the copyright and permission notices are kept.

### Which proxy types does ShardX Launcher support?

You can bind a SOCKS5 or HTTP proxy to each profile, and the launcher resolves timezone, locale and geolocation from the proxy exit country. The README states that full QUIC and WebRTC operation requires SOCKS5 UDP relay support, so HTTP-only proxies will not carry those two protocols.

### Can I use ShardX Launcher without the desktop UI?

Yes. The standalone Python, Node and Rust SDKs ship the browser engine and run without the desktop UI, and the README describes them as intended for scrapers, CI jobs and servers. They are published as shardx on PyPI, @proxyshard/shardx on npm and shardx on crates.io.

### How do I control ShardX Launcher from my own code?

The local HTTP API listens on 127.0.0.1:40325 and uses Bearer JWT authentication. You create, start and stop profiles over it, then obtain a CDP endpoint from the start call. The openapi.yaml file in the repository root is the API contract.

## Sources

- [Issues](https://github.com/ProxyShard/ShardBrowser/issues)
- [License: MIT](https://github.com/ProxyShard/ShardBrowser/blob/main/LICENSE)
- [ProxyShard/ShardBrowser on GitHub](https://github.com/ProxyShard/ShardBrowser)
- [README](https://github.com/ProxyShard/ShardBrowser/blob/main/README.md)
- [Releases](https://github.com/ProxyShard/ShardBrowser/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/proxyshard-shardbrowser