research: Compare CloakBrowser to Patchwright

[dd-avrillo]

https://github.com/CloakHQ/CloakBrowser

[forjd-hermes-bot]

Researched CloakBrowser vs Patchright, with an eye toward whether it changes anything for browse.

TL;DR

CloakBrowser is not just another Patchright-style wrapper. Patchright patches the Playwright driver/protocol behavior and default launch args; CloakBrowser ships a custom patched Chromium binary plus Python/JS wrappers. That means CloakBrowser could cover fingerprint surfaces that Patchright intentionally does not, but it is also a bigger dependency/operational shift.

Given browse currently aliases Playwright to Patchright (playwright: npm:patchright@1.58.2, playwright-core: npm:patchright-core@1.58.2), I would treat CloakBrowser as an optional engine/provider spike, not a replacement yet.

Main differences

Area	Patchright	CloakBrowser
Primary approach	Patched Playwright driver/client behavior	Custom patched Chromium binary + wrapper
Install model	npm i patchright / pip install patchright + patchright install chromium	npm install cloakbrowser playwright-core or pip install cloakbrowser; first launch downloads its stealth Chromium (~200MB)
API compatibility	Drop-in Playwright replacement (require('patchright'), from patchright...)	Claims drop-in Playwright/Puppeteer launch wrapper (launch(), JS launch, Puppeteer path too), but not the same package-level aliasing pattern as browse uses today
Browser support	Chromium only; recommends real Chrome/headed/persistent context for best stealth	Custom Chromium only, currently advertises Chromium 146 builds
Stealth mechanism	Avoids/patches known Playwright leaks: avoids Runtime.enable, disables Console CDP domain, changes default args, closed shadow root support	Source-level C++ fingerprint patches: canvas, WebGL, audio, fonts, GPU, screen, WebRTC, network timing, automation signals, CDP input behavior; also humanize=True interaction behavior
Known compatibility tradeoffs	Publicly documents failing Playwright tests: console/page errors/web errors, websocket routing, init script timing, popup/header quirks, etc. See Kaliiiiiiiiii-Vinyzu/patchright#30	Less obvious compatibility matrix from upstream. Claims Playwright/Puppeteer-compatible, but custom binary + wrapper means we need to verify our daemon/session/CDP assumptions ourselves
Ecosystem/maturity signals	Older project: main driver repo created 2023; Python/Node packages since 2024. Apache-2.0. Main repo ~3.1k stars, Python ~1.3k, Node ~685 at time of research	Newer project: repo created Feb 2026. MIT. ~5.2k stars already, active recent pushes. Python package 0.3.27, npm package 0.3.27 at time of research
Extra features	Extended evaluate APIs with isolated contexts; closed shadow root support	Profile manager, Docker image, proxy geoip/timezone/locale support, WebRTC IP spoofing, humanize=True, Puppeteer compatibility

Practical implications for browse

1. Patchright is easier to keep as the default

   • Current browse integration is package-alias based, so our code can mostly import Playwright as usual while actually using Patchright.
   • CloakBrowser looks more like a launch-provider wrapper. We would likely need an engine abstraction around browser launch/context creation rather than a simple package alias swap.

2. CloakBrowser may be stronger on fingerprint-level stealth

   • Patchright mainly addresses automation/protocol leaks and Playwright defaults.
   • CloakBrowser claims source-level Chromium patches across fingerprint surfaces and publishes specific detection-test claims: reCAPTCHA v3 0.9, Cloudflare Turnstile pass, FingerprintJS pass, BrowserScan normal, etc.
   • Those claims are upstream claims, not independently verified here.

3. Patchright has clearer known breakage

   • Patchright explicitly disables Console CDP, so Playwright features like page.on('console'), page errors, web errors, and some tracing/worker console behavior are expected to fail.
   • That matters for browse if we rely on console capture, page-error capture, websocket routing, init scripts on special URLs, or exact Playwright test parity.

4. CloakBrowser has higher supply/ops surface

   • It auto-downloads a custom Chromium binary, so we would need to think about cache location, platform coverage, CI reproducibility, checksums, Docker size, update cadence, and whether binary download is acceptable in our install path.
   • It is newer despite high traction, so I would not replace Patchright without tests against our actual use cases.

Suggested next step

Create a small spike branch that adds a configurable browser engine:

• patchright = existing default
• cloakbrowser = experimental launch path

Then run both through the same smoke matrix:

• basic navigation/screenshot/DOM snapshot
• persistent daemon/session reuse
• headed/headless behavior
• proxy support
• console/page-error capture expectations
• Cloudflare/Turnstile/FingerprintJS-style detection pages if we have acceptable test targets
• install/first-run behavior in Docker and CI

My recommendation: keep Patchright as default, investigate CloakBrowser as an optional experimental engine. If CloakBrowser materially improves our detection-test pass rate without breaking daemon ergonomics, it could become a selectable stealth backend later.