Attaching to an existing Chrome session vs a fresh browser for your agent
this is a different kind of comparison from the usual proxy shootout, so let me set the frame. in this article Vendor A is attaching your agent to a Chrome that is already running, using Playwright’s connectOverCDP. Vendor B is letting the agent launch its own clean browser with chromium.launch() or launchPersistentContext(). neither costs money. what you pay in is session state, isolation, and how much damage one bad run can do. the proxy angle is real, because the IP your agent exits from is usually tied to how the browser was started, and I will cover that on each axis.
the question behind playwright issue 1985, as I read it, is whether Playwright can drive a Chrome you already have open instead of spawning a new one. the short answer is yes, via browserType.connectOverCDP. the longer answer is that you should do it on purpose, for a specific reason, and not because it feels more “real”. I have run both styles in Singapore on agents that handle my own accounts and my own properties, and the failure modes are very different.
my verdicts, briefly. attach wins when you need a logged-in human session that you cannot or should not recreate, and when a person is watching. a fresh launch wins for anything unattended, anything running in parallel, and anything where a crash should cost you nothing. for a fleet, fresh launch is not close. details below, with the dates attached to anything that can change.
TL;DR comparison table
| Vendor A: attach (connectOverCDP) | Vendor B: fresh launch | |
|---|---|---|
| pricing | free, you run Chrome yourself | free, Playwright is open source |
| session reuse | full: cookies, logins, extensions, open tabs | only what you persist on purpose |
| isolation | weak, shares one profile with whatever else is open | strong, one context per task |
| failure blast radius | large, can close or corrupt your real profile | small, throw the context away |
| protocol fidelity | lower, CDP only, per Playwright docs | full Playwright protocol |
| proxy control | set when Chrome is started | per launch or per context |
| parallelism | awkward, one profile | easy, many contexts |
| support | Playwright issues and docs, Chrome DevTools Protocol docs | same, plus the most common paths are well covered |
| target user | one person with a logged-in browser, supervised runs | anyone running unattended or parallel agents |
Vendor A at a glance
attach means Chrome is already running with a remote debugging port, and your script connects to it over the Chrome DevTools Protocol. you start it yourself, something like chrome --remote-debugging-port=9222 --user-data-dir=/path/to/profile, then call chromium.connectOverCDP("http://localhost:9222") and grab the first context from browser.contexts().
what you get is everything that browser already has. logged-in sessions, saved cookies, installed extensions, the tabs you left open. for an agent working inside an account you own and are allowed to automate, that is the whole appeal. you do not replay a login, you do not hit a second-factor prompt on every run, and you can watch the agent work in a window you are already looking at.
what you give up is a clean separation. the agent and you share one profile. a stray page.close() closes your tab. an agent that navigates somewhere unexpected does it in your real browser, with your real cookies attached.
one change to know about. Chrome stopped honouring --remote-debugging-port against the default profile directory, which is why you now need a separate --user-data-dir. the Chrome team explains the reasoning in their remote debugging port post. as of October 2026 that is how it works, but check the post before you build on it, since browser policy moves.
the Playwright docs also say a CDP connection is lower fidelity than the native Playwright protocol. in practice that means some features behave differently or are missing, and I have seen it surface as odd timing around navigation. test your actual flows rather than assuming parity.
Vendor B at a glance
fresh launch means Playwright starts its own browser process, gives it a new context, and cleans up when it is done. chromium.launch() plus browser.newContext() gives you an isolated, empty, in-memory context. launchPersistentContext(userDataDir) gives you a profile on disk that survives restarts, which is the middle path I use a lot.
the benefit is that the lifecycle is yours end to end. if the agent crashes, the process dies and you start again. the browser contexts docs describe the model: each context is its own isolated session with its own cookies and storage, and you can run many of them inside one browser. that is what makes parallel agents cheap.
the cost is that every context starts blank. you need a login step, or a saved storageState, or a persistent profile. for sites that challenge you on every fresh login, that friction is real, and I would not try to work around it by pretending to be something you are not. if a site wants a person to approve a sign-in, a supervised attach session is the honest answer.
if you are still deciding between Playwright and Puppeteer for any of this, I wrote that up in playwright vs puppeteer for ai browser agents. the attach and launch trade-offs hold in both.
head-to-head
the section titles below are the same axes I use for proxy comparisons. here I am asking what each browser mode means for the IP your agent exits from and for the sessions it holds.
IP pool size
neither mode has an IP pool. the pool belongs to your proxy provider. what differs is how many distinct exit IPs you can actually use at once.
with attach, you have one Chrome and one profile, so in practice you have one exit IP at a time, whatever Chrome was started with. you can launch several Chrome processes on different ports with different --proxy-server flags and different user data dirs, and attach to each. that works, but you are now managing processes by hand.
with fresh launch, Playwright accepts a proxy option at launch and, on Chromium, per context. one browser process can hold many contexts, each on its own proxy. if you have a pool of 50 IPs, you can map them across contexts without starting 50 browsers. winner on this axis: fresh launch.
rotation control
with fresh launch, rotation is simple. new context, new proxy setting, new session. you decide per task. if you want a stable exit for a run, you keep the context. if you want a different one, you open another.
with attach, the proxy is whatever Chrome was started with. changing it means restarting Chrome with different flags, or rotating on the provider’s side, which means the IP changes underneath live tabs. I would not count on Playwright overriding proxy settings on the default context you attached to, and I would test it before relying on it. for a long human-supervised session that is fine. for anything that needs controlled rotation, it is the wrong tool.
if you are choosing between proxy protocols for this, socks5 vs http proxies for a playwright agent that needs authentication covers the auth side, which matters more in launch mode where Playwright passes credentials for you.
geo coverage
browser mode does not change geography. the proxy does. but it changes how easy it is to keep geography consistent with everything else the browser says.
a fresh launch lets you set locale, timezone and geolocation per context, so they match the exit country. an attached Chrome carries whatever your real machine says. if your real machine is in Singapore and your exit IP is in Singapore, that is consistent. if you attach to your own browser and then route it through a foreign IP, the mismatch is yours to notice, and sites you own and operate will see it in their logs.
since I am in Singapore, I will say plainly that when geography matters for my own work, I use a Singapore mobile IP and keep the browser locale Singaporean. that is a narrow case. both of our products are Singapore-only, so they only help if Singapore is the country you need.
connection success rate
I do not have a benchmark for this and I am not going to invent one. connection success depends on the proxy, the target, and the site’s own rules, far more than on how Chrome was started.
what I can say from running both is where each mode fails. attach fails at the connection itself: the debugging port is not open, Chrome was started without the right flag, or a Chrome update changed the policy described above. fresh launch fails at startup in other ways, which I covered in why a browser agent that works locally can time out 30 seconds into startup, mostly around environments and missing dependencies.
for repeated unattended runs, fresh launch fails in more predictable and recoverable ways. that is the part of success rate you can actually control.
speed
attach is faster to the first action. Chrome is already warm, the profile is loaded, extensions are initialised, and you skip the login. for a quick supervised task, that is noticeable.
fresh launch pays for process startup, and for context creation each time. a persistent context avoids part of that. in a long-running worker, you launch the browser once and create contexts as needed, so the startup cost is amortised.
on throughput, the order flips. one attached Chrome is a single profile, so you serialise work or fight over tabs. many contexts in one launched browser let you run tasks side by side. I have no numbers to quote, and the shape of the trade is what matters: attach is quicker for one task, launch is quicker for many.
pricing per GB
the browser mode itself costs nothing per GB, so this axis is only about what each mode does to your proxy bill.
fresh launch starts every context with an empty cache, so it downloads pages and assets again unless you block what you do not need. on a metered residential or mobile plan, that adds up. attach reuses Chrome’s disk cache and warm sessions, which can cut repeat traffic on pages you revisit.
so for a metered proxy, attach can be cheaper per task, and fresh launch needs deliberate trimming: route-level blocking of images and fonts when the task does not need them, and persistent profiles when the same site is hit often. I covered how those proxy types differ in cost and behaviour in residential vs mobile proxies for browser agents. check your provider’s current rates directly, since per-GB pricing changes and I am not going to quote a figure from memory.
session persistence
this is where attach wins outright. the session is the real browser’s session. it survives your script exiting, since disconnecting from CDP does not have to close Chrome. you can run a script, stop it, edit it, run it again, and the tabs and logins are still there. that makes development and debugging much nicer.
fresh launch gives you persistence only if you ask for it. storageState saves cookies and local storage to a file and restores them into a new context. launchPersistentContext keeps a full profile on disk. both work well, but neither carries everything. things that live in the browser process, such as some in-memory tokens, do not come across.
there is one more persistence question, which is the IP. if the account you operate on expects a stable network identity, a rotating exit will cause friction in either mode. for that, a sticky session on a mobile IP is the usual answer. Singapore Mobile Proxy sells real Singapore mobile IPs with sticky sessions. it is Singapore-only, so it solves this only if Singapore is where the account should appear from, and only for work within each site’s terms.
concurrent connections
attach is built for one. several scripts can connect to the same Chrome, and the CDP endpoint will let them, but they share one profile and one set of tabs. two agents clicking in the same context will interfere with each other, and Playwright cannot protect you from that because it does not own the browser.
fresh launch is built for many. contexts are isolated by design, and you can scale to a worker pool. when you outgrow one machine, the question becomes orchestration, and the best ways to orchestrate many playwright browser sessions for a fleet of agents goes through the options I have actually looked at.
use-case verdicts
a supervised agent working inside an account you own
winner: attach. you are sitting there, the account is already signed in, and recreating that state is the expensive part. keep the agent’s scope tight and keep the dedicated profile separate from your everyday browsing. do not point it at your main personal profile.
unattended scheduled jobs
winner: fresh launch. when nobody is watching, you want a crash to cost nothing. a launched context that dies takes only itself down. an attached Chrome that gets into a bad state stays in a bad state until a person notices.
a fleet of parallel agents
winner: fresh launch, and it is not a close call. isolated contexts, per-context proxies, and clean teardown are exactly what a fleet needs. attach cannot give you isolation because the shared profile is the point of attach.
developing and debugging an agent flow
winner: attach, with a caveat. being able to rerun against a live, already-signed-in page speeds up iteration a lot. then move the finished flow to a fresh launch and prove it works from a cold start, because a flow that only works with warm state is not finished.
who should pick Vendor A
pick attach if you are one person automating work inside your own signed-in accounts, you are supervising, and the cost of rebuilding the session is higher than the cost of shared state. also pick it for development. use a separate Chrome profile just for the agent, started with its own --user-data-dir, and treat the debugging port as sensitive. anything that can reach that port can control the browser, so bind it to localhost and do not expose it to a network.
who should pick Vendor B
pick fresh launch if your agent runs unattended, runs in parallel, runs in CI or on a server, or touches anything you would not want to lose in a crash. use storageState or a persistent context for the sites that need a login, and set proxy, locale and timezone per context. if your agent runs on real mobile hardware instead of a desktop browser, that is a different problem. cloudf.one is one option there, renting real Android phones in Singapore on dedicated hardware, each with a persistent Singapore mobile IP, controlled from the browser. it is Singapore-only and I mention it only because phone-based work cannot be solved by either desktop mode here. for how phone agents get judged, see play integrity explained for phone-use agents.
verdict overall
it depends, and I would rather say that than pick a fake winner. attach is a tool for continuity: one human, one live session, supervised work. fresh launch is a tool for control: isolation, parallelism and cheap failure.
if I had to give a default for someone building an agent today, it is fresh launch with a persistent context where login matters. it fails smaller, scales further, and gives you proxy control per task. I reach for attach when I am iterating on a flow or working inside an account that is painful to sign into, and I treat that browser as disposable-ish and separate from my daily one.
one practical note on safety. an agent attached to a real profile can read whatever that profile can read, which makes prompt injection more expensive. I wrote about that in prompt injection for browser agents explained. the smaller the profile the agent holds, the less an injected instruction can reach.
all behaviour described here is as of October 2026, based on Playwright’s current docs and Chrome’s published policy. things like the debugging-port rules and CDP fidelity can change between releases, so check the linked docs against your installed versions. for more like this, the full list is at /blog/.
Written by Xavier Fok
disclosure: this article may contain affiliate links. if you buy through them we may earn a commission at no extra cost to you. verdicts are independent of payouts. last reviewed by Xavier Fok on 2026-10-12.