Chromium fork for automation: 29 patches instead of a script

A stealth plugin rewrites navigator.webdriver and a dozen other values, and a site can still tell. The usual next step is another plugin or a patched driver. We went one layer further down and build our own Chromium, and this guide covers what a fork reaches that a script cannot, and what it costs to keep one in step with Chrome.

What is a Chromium fork for automation?

A Chromium fork for automation is a build of Chromium's source code with changes compiled into the browser, so every value a page reads comes out of the browser's own code instead of being overwritten after the page has started. The Scalebrowser engine is such a fork: it carries 29 source-level patches and no injected JavaScript, counted on 29 September 2026. A change against detection can live in three places, and each place reaches a different set of signals.

The table describes reach, not rank. A fork can make a value true inside the browser, and it can just as well ship a wrong value to every profile at once. That is why every patch in our engine is measured against a real Chrome on the same machine before it ships.

Why can a script not hide the control plane?

A script cannot hide the control plane because the control plane delivers it: the automation library injects the script into every page over the same protocol a detector looks for, and an object that was rewritten can be caught in the act. The maintainers of rebrowser-patches, a set of patches for Puppeteer and Playwright, say so in their README:

Always keep in mind: the less you manipulate browser internals via JS injections, the better. There are ways to detect that internal objects such as console, navigator, and others were affected by Proxy objects or Object.defineProperty.

The best-known script shows where that road ends. puppeteer-extra-plugin-stealth ships 17 evasions, has had no commit since 1 March 2023 and carried 238 open issues when we read it on 22 September 2026. One of its evasions reports, by default, the vendor "Intel Inc." and the renderer "Intel Iris OpenGL Engine" on every machine, whatever graphics card really draws the page. A value asserted by a script has nothing behind it, and a page can compare it with what the hardware produces.

Moving the change into the driver removes the injection and keeps the protocol. Ian L. Paterson ran 7 tools against 31 targets, 651 verdicts in all, and concluded in May 2026 that "Playwright forks fail regardless of patch quality". Every stealth browser can be sorted along that line: by the layer it changes, not by the number of values it rewrites. FlareSolverr, which starts one Chrome per request, is covered in FlareSolverr in 2026.

What does a fork have to maintain?

A fork has to maintain four things a script never needs: a place on Chrome's release train, patches that still apply to each new milestone, a signature on every build, and a way back when a build turns out bad.

• The release train. Chrome reached stable with milestone 152 on 25 August 2026, 153 on 8 September and 154 on 22 September, and, as of September 2026, Chromium's schedule lists 155 for 6 October: one milestone every 14 days. Browserbase, which forked Chromium for its cloud browsers, wrote in November 2025 that it cut a full Chromium build from "3-4 days" to "about an hour" to keep up with that pace.
• The patch rebase. Each milestone moves the code underneath the patches. When we carried our series from 151 to 154 on 12 September 2026, 23 of 30 source diffs applied unchanged and 7 needed work by hand, 15 rejected hunks spread over 13 files.
• Signing. A customer installs a browser binary they cannot inspect, so every build is signed, and a signed manifest names every file with its own digest. The engine page of the documentation describes the check at install and again at every launch.
• Rollback. The previous build stays installed, so going back is one command without a download, and profiles follow the pinned build in both directions.

Falling behind is the cost that never shows in a build log. A browser that reports an older Chrome than the people around it sits in the thin tail of the version distribution, and no patch in its source can fix that.

On 26 September the two builds also sent the identical TLS fingerprint, JA4 t13d1517h2_8daaf6152771_cb7bf5808d99 with 17 extensions. The version string and the handshake have to move together, because a server needs only the user agent and the extension count to find a mismatch.

Scalebrowser gives each agent its own isolated browser with a persistent identity, on your own machine, so a run stays signed in, handles the captcha and finishes without anyone watching it.

See how Scalebrowser does it

Which detection does the fork act on?

The fork acts on what the browser reports: JavaScript values, request headers, the TLS handshake and what the graphics card draws. It does not decide how the browser is driven. A page that watches for the automation protocol itself, the subject of CDP detection by pages, reads the control plane, and that layer needs its own answer in the driver and in the input path above the browser. A fork without that answer is half the work, and so is a careful driver on a stock browser. Why curved pointer paths are not enough is covered in ghost-cursor and Bezier paths.