Drive a browser you're already logged into
The real-session pattern: run a dedicated browser with your logins, point automation at it, and reuse that warmed-up session instead of fighting a login every run.
You need data that sits behind a login, or you need an agent to act inside an app you're signed into. Automating the login itself is the hard, fragile path: single sign-on, two-factor prompts, cookie handling, and a security system that flags the attempt. The better move is to skip it. Log in once, by hand, in a browser your automation can reach, and reuse that session from then on.
That's the real-session pattern, and it's the surface I reach for most.
How it works
Run a dedicated browser with remote debugging turned on. That opens a control channel, the Chrome DevTools Protocol (CDP), on a local port: with it, your code can navigate, click, type, and read the page in a browser that's already running. Log into the sites you care about once, in that browser. The session lives in its profile and survives restarts, so you sign in again only when the site expires you. Then point your automation, a script or an agent, at the debugging port, and it drives the live, logged-in browser.
Why this beats a fresh browser every run: a real, warmed-up, logged-in browser is the hardest thing for a site to tell apart from a person, because it isn't pretending to be one. That matters most on sites that fight automation, which is Part 6.
Use a separate browser, not your everyday one
Don't turn on remote debugging in the Chrome you browse with. Automation belongs in a dedicated browser profile, kept apart from your daily one. Two reasons. First, you don't want an automated job clicking around in the same window and session you're using. Second, launching your everyday browser for automation can make it register as your real browser on the system and take over that identity. A clean choice is Chrome for Testing, a build made for automation that stays separate from the Chrome in your dock.
One shared browser, or one per job
Two shapes of this pattern, and the choice comes down to whether jobs should share a session.
Shared and always on. One dedicated browser, logged into your sites, left running. Every job attaches to it. One login, reused everywhere, nothing to spin up per run. This is the low-overhead default when your jobs are friendly and you're the one driving.
Isolated, one per run. A fresh browser launched for a single job and closed after. Reach for this when the site is hostile and you want its session kept out of your shared, heavily-used profile, when you need clean state every run, or when a crash must not take down a browser other jobs depend on. Separate profile, separate blast radius.
If none of those apply, share one browser. It's less to maintain.
The rules that keep it working
Keep the debugging port on your own machine. It's an unauthenticated control channel: anything that can reach it can drive your logged-in browser. Bind it to localhost and don't expose it on your network.
If you share one browser across jobs, disconnect when you're done rather than quitting it. Closing a browser that other jobs rely on drops every session, not just the one you were using.
And carry the safety rule from Part 1: this browser lives in a visible window, and activating a tab in it grabs focus. For a job that could run unattended or during your workday, drive it headless or use a headless surface, so it can't take over your screen.
When to reach for this, when to skip it
Reach for it when the task needs a login that outlives a single run, or when looking like a real session is what gets you through. Skip it when there's no login at all, where a throwaway browser is simpler (Part 5), or when you're still learning an unfamiliar site and want an agent that can see the page and react (Part 3).
Next up, Part 3: the two ways an agent drives a browser, and why you explore with one and repeat with the other.