OpenClaw’s setup docs tell you to point the agent at your real Chrome, and that advice holds up right until you remember you have three of them.

Work profile. Personal. Some client account you were made to create because their SSO tenant refused your main address. Chrome treats each one as a fully separate cookie jar and gives them folder names that have nothing to do with the names in the avatar menu. So when an agent attaches over CDP and reports “connected,” it’s telling you the truth about a socket and nothing whatsoever about your session.

Then it opens Gmail and finds a sign-in page. And you burn forty minutes debugging a relay that was never broken.

The only screen that settles it

chrome://version, typed into the window the agent is supposedly driving. Two lines matter: Profile Path and Command Line.

Profile Path ends in a folder name. Default, or Profile 1, or Profile 4. That string is the actual identity of the window, and the friendly label you see in the avatar bubble is cosmetic decoration stored in a JSON file called Local State, which means the profile you think of as your primary one has no particular reason to be the one Chrome calls Default. Mine sure isn’t. My work profile, the one holding Workspace and Okta, is Profile 2, and Default is a personal account I set up years ago and barely touch.

Command Line shows the flags Chrome actually launched with. If --remote-debugging-port=9222 isn’t in that list, you’re looking at a browser you didn’t start.

user-data-dir is the apartment block, profile-directory is the unit

This distinction eats more people than any other part of relay setup.

--user-data-dir points at the container that holds every profile plus all the shared state. --profile-directory selects one profile inside it. Most agent guides mention the first flag and go silent on the second, which is how you produce a configuration that is technically correct and still lands in an empty room.

Because when you omit --profile-directory, Chrome doesn’t pick the profile you used most recently, or the one that was on screen thirty seconds ago. It picks Default. Always.

There’s a second trap sitting directly behind that one. Since Chrome 136, Google refuses to honor --remote-debugging-port pointed at your normal user data directory, on the reasonable theory that any local process could otherwise vacuum up every cookie you own. So the tool falls back to a scratch directory, launches a spotless browser, and cheerfully reports success. That’s the blank-profile failure mode that keeps showing up in issue trackers.

Launching Chrome a second time does nothing

Chrome is single-instance per user-data-dir. Your second launch hands its flags to the process already running and exits. A window appears. Your flags evaporated.

The workaround, and why I gave up on it

You can make it work. Quit Chrome completely, and I mean completely, including the background tasks that keep the process alive after the last window closes, so check Activity Monitor or Task Manager before you trust it. Copy your user data directory somewhere else. Relaunch with both flags: --user-data-dir=/path/to/the/copy and --profile-directory="Profile 2". Confirm on chrome://version that the Profile Path ends in the folder you meant.

That gets you an authenticated Chrome the agent can drive. For a while.

Then the copy drifts. Cookies in a duplicated profile go stale on their own schedule, Okta re-prompts for device trust because the copy lost whatever binding the original had, and Workspace occasionally decides the session looks wrong and invalidates it. Now you’re maintaining two Chromes with divergent bookmarks, divergent extensions, and one of them holds logins that expire on a timeline you can’t see. I did this for about three weeks before admitting the whole arrangement was crap.

The deeper problem is that the entire approach treats your logged-in browser as something to be reached from outside, over a debugging port that Chrome’s security team is actively narrowing every release. Your agent can’t see that you’re logged in because it’s standing in a different building.

Running inside the profile instead of next to it

dassi is a side panel extension, which sounds like a smaller idea than a relay until you notice what it skips. There’s no user-data-dir to specify, because the extension is installed in a profile and runs in that profile. Open the panel in your work window and it operates on your work session. Switch to the personal window, open the panel there, and it’s your personal session. The profile question dissolves rather than getting answered, since an extension has no way to be in the wrong one.

It’s on the Chrome Web Store, free, and works with your ChatGPT login or your own API key.

None of this makes CDP useless. If you’re scripting headless runs on a server, ports and data directories are exactly the right abstraction. But for the thing most people actually want, which is an agent that can read the Salesforce tab open in front of them, the remote-attach model asks you to reconstruct a browser you already have.

Anyway. Go check chrome://version in whatever window your agent claims to be driving. I’d give it even odds it says Default.