Every guide, comparison and detector run we have published under automation.
launchPersistentContext keeps cookies between runs, which is half of an identity. The other half is the fingerprint staying identical too, plus the API differences that trip people up. A practical guide with the gotchas.
109 accounts, 1,989 logged actions, zero interactive challenges and zero re-logins across 32 warm-up sessions. The harness, the code, the per-batch variance, and what the free tier actually covers.
A script that opens one browser per task creates one profile per task, and every tool that lists profiles then has to list them forever. Temporary profiles go in a separate tree the desktop app never reads, and nothing in it is deleted for you, which is the point.
A launch that jumps to the front is fine once and unusable in a loop, and going headless to avoid it changes what the page can measure. There is a third option: keep a real, normally sized, visible window and stop only the part that interrupts you.
Most MCP browser tools hand the model a fresh context per call, so anything behind a login is unreachable. Here is the setup, why session persistence across tool calls is the part that matters, and what still goes wrong.
Stealth plugins are free, they work, and for a one-off script we would use one too. The failure is not detection on day one, it is what happens on the release that moves the goalposts, and what a plugin never covered in the first place.