Choosing a Browser for Agents: Playwright’s Approach and chrome-use Are Not the Same Thing

Updated on October 7, 2026: This article compares creating a new browser context with connecting to an existing session. Playwright, Puppeteer, and browser-use also support persistent configurations or ways to connect to an existing browser, so they cannot be summarized as only being able to open an empty browser. Fingerprint tests only represent a specific environment and do not guarantee that all websites will allow access. For current installation and connection methods, see the chrome-use documentation (and the up-to-date comparison with other tools).

People often ask: since we already have Playwright, Puppeteer, and browser-use, what different problem does chrome-use actually solve? My answer is that they are really answering two different questions. The former asks, “How do I open a browser with a program?” The latter asks, “How do I let a program use the browser you are already using?” That dividing line determines what each one is good at, and where each one’s fatal weakness lies.

A Disposable Browser, or Your Browser

Playwright, Puppeteer, and browser-use start a new process, open a browser with a clean profile, and then control it through a debugging protocol. This browser is disposable: it has none of your cookies, no logged-in state, and disappears when closed. Cookies, fingerprints, and concurrency all have to be managed by you.

chrome-use does not start a new browser. It connects to the Chrome that you already have open at this moment, the one where you are already logged into everything. The connection goes through a browser extension plus native messaging, rather than --remote-debugging-port.

This may sound like merely a difference in “whose session is being used,” but the implications go much deeper than that.

A Chain of Related Differences

Login. If an empty browser needs to access a page behind login, you have to run the login flow in your script, or maintain your own set of cookies: await context.addCookies(savedCookies). You first have to obtain those cookies, and then keep them fresh. With chrome-use, this step is zero: you are already logged in, and once connected, you are inside the session.

Fingerprinting and detection. An empty automated browser carries a whole set of markers: navigator.webdriver=true, headless rendering flaws, and the common Runtime.enable leak when driven through CDP (rebrowser specifically detects this). chrome-use’s extension path uses your real profile; the specific detection markers should be based on the documented tests. In CreepJS testing, its bot score was 0%.

That popup. Chrome 136 restricts remote debugging for the default profile; port configuration and authorization requirements vary by version and connection method. chrome-use uses an extension, so after installing it once, there are no further confirmations.

Concurrency. In chrome-use, each --session gets its own independent colored tab group. Multiple agents can share the same real Chrome without getting mixed up or fighting over your own tabs.

These are not four separate selling points. They are the natural chain of consequences that follows from the choice to “use your browser.”

Applying It to a Real Task

Take a concrete example: exporting data from an admin backend where the data only appears after paging through three screens.

With Playwright: launch opens an empty browser, runs the login flow—entering the username and password, possibly hitting a CAPTCHA and getting stuck—waits for JS rendering, turns the pages, and then scrapes. The login and CAPTCHA steps often stop the script right at the beginning. With chrome-use: connect, inspect the structure with snapshot -i, and use extract to pull it into JSON. You are already logged in, and the page is already in front of you, so the first two barriers simply do not exist.

The hard part is never “scraping.” It is first getting to the point where scraping is possible. That is also the boundary I use to decide which tool to use.

So Don’t Ask Which Is Better. Ask What You Are Doing

There is no hierarchy here; there is a division of labor.

For end-to-end tests in CI, where you need a clean environment, reproducibility, and dozens of parallel browsers, Playwright and Puppeteer are built exactly for that. Forcing chrome-use into that scenario would be awkward, and you probably do not want tests running in the browser you use every day. For one-off scripts, where logging in again is acceptable and being flagged is not a concern, any of the three new-browser approaches can work, and browser-use also comes with LLM orchestration. But as soon as a task involves “my logged-in state,” “this site has anti-bot measures,” or “it needs to look like a real person,” the balance tilts toward chrome-use. As for simply wanting Claude to open a browser by itself, Claude’s official Chrome extension is enough; it only drives Claude, though. If you want to use any agent or your own scripts, that is when chrome-use comes in.

Remember it in one sentence: testing wants a disposable browser, where cleanliness and reproducibility matter most; agent work often wants a browser you are already using, where a real session and not getting blocked matter most. Once you are clear about which job you are doing, the choice stops being difficult.