I spent twenty minutes on Hacker News this morning counting browser agents on the front page. An open-source autoscaling AI browser agent near the top, Yamak a few slots below it, and Desktop Agent Center further down doing local automation through global hotkeys. Different teams, different stacks, same first-run experience: install it, hand it a task that touches Gmail or Jira, and watch it open a browser that has never met you.

Blank profile, no cookies, and a login wall where the work was supposed to start.

The OpenClaw threads get the loudest version of this because OpenClaw actually gives you a choice of how the browser gets attached, and choice is where the confusion lives.

Three modes, and only one of them knows who you are

The managed browser is the default nearly everywhere. Your agent shells out to Playwright or Puppeteer, which downloads its own Chromium build and points it at a scratch --user-data-dir somewhere under /tmp. That directory was created ninety milliseconds ago. It contains nothing. So the agent lands on mail.google.com and gets the account picker, every single time, no matter how logged in you are on the desktop three inches away.

Browser Relay is the one people want and the one people misconfigure. A relay bridges the agent to a Chrome instance you’re already running, through an extension or a local socket, so the tab it drives is a tab inside your real profile with your real cookies. When it works it works well. When it doesn’t, it’s almost always because the relay attached to a different Chrome than the one holding your session, or because Chrome restarted and the relay kept reporting a connection to a process that quietly became something else.

Remote CDP is the one that sounds most powerful and helps least. You launch Chrome with --remote-debugging-port=9222 and the agent speaks the DevTools Protocol to it. Fine, except two things bite. If your normal Chrome is already open on that profile, the new launch just hands the arguments to the running process and exits, and no debugging port ever opens, which is why so many people swear they set the flag and the agent still connected to something empty. And if the agent runs on a VPS, the port it dials is a browser sitting in a datacenter, on a profile that has never seen your password manager.

The blank Chrome profile isn’t a bug

Chromium isolates profiles on purpose. A fresh user-data-dir with no cookies is the security boundary working exactly as designed. Your agent isn’t broken. It just got born five seconds ago with no memory.

Copying your profile folder will waste your afternoon

This is the fix everyone tries second, right after restarting things. Copy ~/Library/Application Support/Google/Chrome/Default (or the AppData equivalent on Windows) into the temp directory the agent uses, point the flags at the copy, done.

It isn’t done. Chrome holds a SingletonLock on a live profile, so the copy either fails or gives you a torn snapshot of a database mid-write. Worse, the cookie file is encrypted with a key that lives in the OS keychain, not in the profile: macOS stores it under “Chrome Safe Storage” and Windows wraps it in DPAPI bound to your user account, so a profile folder moved to a server decrypts into garbage even when every byte copied cleanly. Then there’s the layer nobody warns you about, which is that Google, Okta, and most enterprise SSO providers bind sessions to a device fingerprint and a rough IP location, so a session cookie that suddenly appears from a Hetzner box in Nuremberg gets a re-auth challenge rather than a mailbox.

And now you have a second copy of every authentication cookie you own sitting in a temp folder that no cleanup script will ever touch. That’s a hell of a price for skipping one login screen. I’ve watched people spend a full evening on this and end up with an agent that’s still looking at the account picker, just from a more expensive angle. There’s a broader map of these connection styles in three ways AI agents connect to your browser if you want the version with more architecture and fewer complaints.

So what already has the session?

The tab you have open right now.

That’s the whole reason Dassi runs as a Chrome side panel instead of spawning anything. There’s no profile to select, no debugging port to open, no relay handshake to keep alive across a restart, because the agent executes inside the browser session you’re already authenticated in. Your Gmail is logged in for the agent for the same boring reason it’s logged in for you. Bring your own API key or sign in with your ChatGPT subscription; the model runs where you point it, and the browser context comes free.

Dassi won’t run unattended at 3am while your laptop sleeps, and if you need a hundred parallel browsers churning through a scrape queue, go use the autoscaling thing from Hacker News. Different job. But most of the tasks people actually hand these agents are triage, drafting, form-filling, and pulling numbers out of a dashboard that requires SSO, and every one of those dies at a login wall. We wrote more about that gap in your AI browser agent can’t see that you’re logged in.

Somewhere there’s a person tonight, four hours into debugging a --profile-directory flag, who could have just opened a side panel. I was that person once, on a Tuesday, with a Jira board I could see and my agent could not.