Real Browser Kernels vs Patched Chromium for Stealth Agents

Bad bots make up 37% of internet traffic as of 2026, and that volume forced anti-bot vendors to stop checking headers and start checking everything else: how a page renders, how a TLS handshake orders its ciphers, how a mouse moves across a screen. The old tells are dead. A stealth agent built on Playwright, Puppeteer, or Selenium runs a real Chromium or Firefox binary now, so nobody's catching python-requests in a user-agent string anymore. Whether an automated browser gets through comes down to an architecture, chosen deliberately, not a single clever trick. It's an architecture, chosen deliberately, with a failure mode the engineer already understands going in.

Detection has moved down the stack, layer by layer, until it reached places a script can't easily reach. First came JavaScript checks: navigator.webdriver, leftover CDP listener artifacts. Then rendering and hardware fingerprints, canvas hashes and GPU/OS consistency validated at the C++ level, below anything a content script can touch. Then TLS and network fingerprints, JA3/JA4 cipher order and HTTP/2 frame sequencing, hard to fake from a browser's JS layer but not impossible from the client side (tools like curl_cffi exist for exactly this). And finally behavioral biometrics: mouse curves, scroll inertia, typing cadence. PerimeterX and DataDome both reject input that arrives at constant, machine-timed intervals. Cloudflare doesn't run these as separate gates either. It folds them into one risk score, network inspection plus TLS fingerprinting plus JS challenges plus behavior, so beating one layer buys nothing if the other three still flag the session.

The three architectural philosophies engineers choose between

Three genuinely different philosophies exist here, not points along one dial marked "more stealth." Each solves a different problem, and each breaks in a different, predictable place.

Philosophy A, runtime injection, patches a browser after it launches: JavaScript bolted on top to hide signals anti-bot vendors already know to look for. It's fast to build and fast to deploy, and just as fast to decay, because it never touches TLS or rendering, only the JS layer sitting on top of them.

Philosophy B, source-level patching, compiles the lie into the browser itself, below the JavaScript boundary, so the fake signal shows up consistently in every worker and every iframe without needing to be re-applied by hand. That reach costs a lot in build complexity and demands constant rework every time Chromium ships a new version.

Philosophy C, CDP-minimal control, doesn't patch anything. It drives a real, unmodified system Chrome directly over a low-level browser control protocol, with no WebDriver layer and no Playwright shim sitting in the control plane to begin with. Rather than hiding an artifact, it just declines to create one.

The distinction between B and C determines which detection layer a browser can defeat and which it cannot. Philosophy B forges the browser's identity at the binary level, faking canvas output, GPU strings, font lists. Philosophy C doesn't forge anything, it removes the control-plane fingerprint that would otherwise expose the automation framework driving the browser, leaving the browser's own unmodified fingerprint untouched underneath. Both are legitimate answers to different questions, and conflating them is a common misread of this whole space.

Each philosophy fails on its own terms. A fails once a vendor starts fingerprinting the patch instead of the thing the patch was hiding. B fails when the patch set drifts out of sync with a new Chromium release, so the binary version and the claimed fingerprint stop matching. C fails on any target that gates on rendered behavior or device-level fingerprinting instead of control-plane artifacts, since removing the CDP shim does nothing for a canvas hash or a WebGL string.

Where runtime injection tools still work and where they break

puppeteer-extra-plugin-stealth is the classic example of Philosophy A: a set of JS evasion patches covering navigator.webdriver, plugin array shape, Chrome runtime object quirks. None of it touches TLS or network-layer signals, and the core package hasn't seen a meaningful update since March 2023. Its patches were written against Chrome 109 through 112-era detection logic. Sites running Cloudflare Bot Fight Mode or DataDome's newer behavioral checks catch it consistently now.

playwright-stealth v2.x is the healthier version of the same idea. It's actively maintained, with v2.0.2 out in February 2026, and it's the better call for anyone on a Python/Playwright stack who still wants a runtime-injection approach rather than a rewrite.

undetected-chromedriver patches the ChromeDriver binary directly and adjusts Chrome launch flags. It's Python-only, and it's really a tool for bumping an old Selenium script rather than a production stealth layer. At 2026 detection levels, it clears fewer than 10% of Cloudflare Pro challenges by itself, and needs residential IPs and a captcha solver stacked on top to do anything useful. Treat it as a starting point for legacy code, not a finished answer.

The pattern across all three is the same one. Anti-bot vendors stopped looking only for the original signal and started fingerprinting the patch itself. Injected JS leaves its own trace, and that trace is now as recognizable as navigator.webdriver ever was.

CDP-minimal control: what nodriver and zendriver remove from the detection surface

nodriver is the direct successor to undetected-chromedriver, built by the same author after recognizing that patching WebDriver-based tools was a losing fight: detection vendors were learning to spot the patch, not just the underlying tell. It drives system Chrome straight over CDP, with no Playwright shim anywhere in the control plane. It has 4,649 GitHub stars, and last saw a push on 13 May 2026.

In Ian Paterson's single-IP benchmark against 31 targets protected by a bot-mitigation service, nodriver scored 28 OK out of 31 targets. The reason tracks with the architecture: it drives real Chrome with no Playwright shim, and that shim is exactly the layer those particular targets gate on. AGPL-3.0 carries real obligations, and the project's pace of pushes is worth watching before it becomes a load-bearing dependency.

zendriver forked nodriver to fix outstanding bugs and take community contributions the original project wasn't accepting. It's smaller, around 1,400 stars, but more recently active, with a push on 9 August 2026 against nodriver's 13 May.

The ceiling on Philosophy C is structural. Removing the CDP artifact does nothing for canvas hashes, WebGL strings, or GPU identity, because those never depended on the control plane. On any target gating on device-level fingerprints instead of automation-framework artifacts, a CDP-minimal setup still hands over the real host machine's signature, honestly and in full.

What source-level Chromium patching closes and what it costs

CloakBrowser represents Philosophy B at its most complete: 87 separate C++ patches compiled directly into the Chromium binary, covering canvas, WebGL, audio, fonts, GPU strings, screen properties, WebRTC, network timing, automation-signal removal, and CDP input mimicry. It was last tested in August 2026 against Chromium 151. A humanize=True flag adds Bézier-curve mouse movement, per-character keystroke timing, and realistic scroll behavior baked into the same compiled binary rather than injected at runtime, and it scored a 0.9 on reCAPTCHA v3, server-verified as human-level.

It's built as a drop-in replacement for Playwright or Puppeteer: swap the import, keep the same API, install with pip install cloakbrowser or npm install cloakbrowser, and the patched binary auto-downloads and caches locally (it runs over 200MB). It ships for Python, JavaScript/Node, and.NET/C# via NuGet, across Linux x64 and ARM64, Windows x64, and macOS. A free tier exists, and the paid Pro tier adds persistent profiles across sessions, which defeats incognito-mode detection specifically.

What source-level patching buys that no injection tool can match comes down to three things. The patch lives below the JavaScript boundary, so no page-side script can enumerate it. It applies automatically to every execution context, meaning workers and iframes stop leaking real device data without extra code. And the fingerprint sits inside the compiled binary itself rather than being applied at runtime, so there's no timing window where the original, unpatched signal is briefly visible before a script fires.

The cost is real and ongoing. The binary is large, and every new Chromium release means re-patching 87 separate points of the source tree, a treadmill with no finish line. And the benchmark data carries a useful humbling detail: in Paterson's single-IP test, curl_cffi, a roughly 6MB Python wheel with no browser at all, tied CloakBrowser's fully patched Chromium at 26 OK out of 31. On some targets, TLS fingerprint decides the outcome and rendering fidelity barely matters. A patched browser isn't automatically the right tool just because it's the most thorough one.

Firefox-based engine patching: Camoufox and the TLS shape trade-off

Camoufox takes Philosophy B and applies it to Firefox instead of Chromium: a fork with canvas, WebGL, screen geometry, and navigator-property spoofing done at the C level, using randomized values that stay internally consistent with each other. It's MPL-2.0 licensed and free, with 11,057 GitHub stars as of 13 August 2026, and a push as recent as 12 August. In the techinz/browsers-benchmark, Camoufox cleared 100% of tested targets. There's a documented maintenance gap in 2025, which anyone taking a long-term dependency on the project should weigh even against the current activity.

The interesting trade-off is TLS shape, not raw stealth. Firefox's TLS handshake orders its cipher suites differently than Chrome's, and that difference is detectable. But detectable isn't the same as blocked: plenty of anti-bot configurations whitelist Firefox-shaped traffic specifically because they're tuned to catch Chrome-shaped automation, which is far more common in the wild. So on a target built to block Chrome bots, Camoufox wins by default. On a target that specifically flags Firefox-shaped TLS, it loses the same advantage. It's a different risk profile that only pays off if it's matched to the right target.

The benchmark numbers need one more caveat. A 100% clear rate under rotating residential proxies isn't the same claim as 100% on a single fixed IP, since a Firefox fingerprint can accumulate reputation on a static address over time in a way it can't when the IP changes every request. Methodology shapes the number as much as the tool does.

Set against Patchright, the choice comes down to what's already built. Camoufox holds up better against hard fingerprinting targets but runs slower. Patchright is the cleaner drop-in for anyone already on Playwright, and it keeps the same Chromium engine underneath.

Commercial infrastructure: what managed source-patched kernels add that open-source tools don't

The patch treadmill is the real, recurring cost of Philosophy B, and it's the reason commercial infrastructure exists. Every Chromium release demands a re-patch. Every Firefox release demands a re-patch. A repository that goes quiet for two months isn't neutral, it's quietly losing ground against detection systems that keep shipping updates on their own schedule. That's the actual shape of the build-versus-buy decision.

Kameleo runs a dual-kernel setup, Chroma for Chromium and Junglefox for Firefox, under what it calls a "Multikernel" architecture: it downloads the specific Chroma kernel version that matches the major Chrome version named in the selected fingerprint, at runtime. New Chroma kernels ship closely after each stable Chrome release. That matters because binary-version-to-fingerprint mismatch is one of the more common detection vectors on modern anti-bot systems, and matching kernel version to claimed fingerprint per profile closes exactly that gap. Kameleo's most recent update fixed a WebRTC leak that exposed the real IP behind a proxy, plus added protection against port scanning.

Browser Use Cloud maintains its own in-house Chromium fork, patched and kept current on a rolling basis, running headless on the latest major Chromium build across macOS, Windows, and Linux, with tens of thousands of real device fingerprints and in-house captcha solving. In its own stealth benchmark, run across 71 sites selected from 300,000 production security-check events, Browser Use Cloud scored 81%, ahead of Anchor at 77%, Onkernel at 67%, Steel at 47%, Browserbase at 42%, and Hyperbrowser at 40%. Broken out by vendor, the same tool cleared Cloudflare at 93%, Akamai at 85%, and PerimeterX at 81%. An independent benchmark, Halluminate's BrowserBench, run across 296 separate tasks, put Browser Use Cloud at 84.8%, ahead of Hyperbrowser at 76.4%, Anchor at 76.0%, Steel at 73.3%, and Browserbase at 70.3%. As a sanity check on the whole exercise, a bare headless Chromium baseline scored just 2% and a headful baseline scored 50%, which suggests the gaps between tools reflect real differences in stealth engineering rather than differences in task difficulty.

None of these numbers should be read as fixed. Proxy quality shifts hour to hour, site configurations change without notice, and captcha difficulty moves around too. Consistent leadership across two independently run benchmarks is a real signal that does not carry forward unchanged. The browser-use benchmark itself is open-source, published at github.com/browser-use/benchmark, for anyone who wants to check the methodology directly.

The patch gap: why even source-patched Chromium carries a structural security risk

Every one of these architectures, A, B, and C alike, inherits a problem that has nothing to do with stealth and everything to do with maintenance. A source-patched Chromium binary is still Chromium underneath 87 separate patches, and Chromium ships security fixes on its own release cadence, often in response to actively exploited vulnerabilities. A patched fork has to take the upstream security fix and reapply its own patch set on top of it, and that reconciliation takes time, sometimes days, sometimes longer, depending on how invasive the new patch needs to be.

That gap between an upstream Chromium security release and a patched fork's equivalent release is a real window, and it exists independent of how good the stealth engineering is. A binary can defeat every fingerprinting check on the market and still be running on a rendering engine with a known, unpatched vulnerability, because the fork's maintainers haven't caught up yet. This is a structural cost of choosing Philosophy B at all, not a flaw specific to CloakBrowser, Camoufox, Kameleo, or any single product named here. It's a structural cost of choosing Philosophy B at all: the deeper the patch reaches into the source tree, the more surface there is to resynchronize every time upstream moves, and the more that resynchronization becomes its own point of failure, separate from and every bit as consequential as detection itself.