The Runtime.enable signal
To run JavaScript in a page, Puppeteer and Playwright need to know the page's CDP execution context. By default they obtain it by issuing the CDP command Runtime.enable, which tells Chrome to emit execution-context events. The side effect is that calling Runtime.enable is observable from inside the page, which gives an anti-bot system a signal that a DevTools client is attached - the same leak covered in detail under CDP detection. rebrowser-patches avoids the automatic Runtime.enable on each frame and obtains or creates the execution context by other means.
How the patch works
The patch offers selectable modes for wiring up execution contexts without the default automatic call. In the default addBinding mode it creates a binding in the main world and recovers the context ID that way; an alwaysIsolated mode works only in isolated contexts created via Page.createIsolatedWorld; and an enableDisable mode calls Runtime.enable then immediately Runtime.disable to capture the context events within a narrower window. Functionally the API is unchanged - it is a drop-in replacement - and the only behavioural difference is how and when execution contexts are established at the CDP layer.
What it does and does not cover
rebrowser-patches is narrowly and deliberately scoped: it addresses one specific CDP-layer signal and nothing else. It does not touch the TLS fingerprint, the IP you connect from, or the JavaScript fingerprint surface that a plugin like puppeteer-extra-stealth targets. That focus is a strength - it is current and maintained against recent Puppeteer and Playwright versions - but it means rebrowser is one layer to combine with others rather than a complete approach. A real-world detector weighs many signals, and closing the Runtime.enable one leaves the rest unchanged.
