I was reading an OpenClaw support thread last week where someone had spent two hours debugging why their agent kept landing on the Gmail login screen. They had Browser Relay turned on. They were logged into Gmail. The agent still saw a stranger’s empty inbox, basically, because it never touched their actual session. The thread had eleven replies and none of them fixed it.

This confusion comes up constantly, and it almost always traces back to the same root: people treat “Browser Relay,” “the managed browser,” and “my Chrome” as if they’re one thing. They are three different things, and only one of them runs the task in the tab you care about.

Three modes, and only one knows you’re logged in

OpenClaw can drive a browser in a few distinct ways. The managed browser is the default for a lot of setups. OpenClaw launches its own Chromium instance, controls it directly, and that instance boots from a clean profile every time. No cookies. No saved sessions. Nothing. It’s a brand-new browser that has never met you.

Then there’s remote CDP, where OpenClaw connects to a Chrome running somewhere else over the DevTools Protocol, often on a VPS or in a container. Useful for headless automation. Also completely blind to your local logins, because that Chrome lives on a server that has never seen your laptop.

Browser Relay is the odd one out. It connects OpenClaw to the Chrome already running on your machine, through a relay extension that bridges the agent and your live browser. This is the mode where the agent can actually use the Gmail tab you’re staring at, the Salesforce session you logged into this morning, or the internal dashboard behind your SSO that no headless server will ever reach without you handing over credentials it has no business holding. Relay is the one that matters for real work, and it’s the one people misconfigure most.

Why “relay is on” doesn’t mean “relay is working”

The Gmail-login mystery almost always hides in one place: Chrome profiles.

Chrome stores cookies and sessions per profile. You probably have more than one without thinking about it. The Default profile, a work profile, maybe a throwaway you made for testing two years ago. Each profile is a separate sealed box of logins. And Browser Relay has to attach to a specific one.

So you flip relay on, the connection succeeds, the status light goes green, and you assume you’re done. But if the relay attached to the Default profile while your real logins live in “Profile 2,” the agent opens Gmail and sees nothing. It’s connected to your local Chrome. It’s just connected to the wrong room inside it. The agent didn’t fail. It did exactly what you told it, against an empty session, which is somehow more annoying than an outright error.

Restarts make this worse. Navigate away, quit Chrome, reopen it, and the relay can reattach to a different profile or lose the binding entirely. People report the agent working perfectly for twenty minutes and then quietly slipping back into a logged-out state after a single window close. The fix is fiddly profile-pinning that most users never find documented anywhere obvious.

A quick gut check

Open the tab. Look at the top-right avatar. Is that the account you want the agent using? If you can’t answer instantly, neither can the relay.

The whole problem is that there’s a browser to choose at all

Step back and the pattern is obvious. Every one of these failure modes exists because OpenClaw sits outside your browser and has to reach in. Managed browser, remote CDP, relay-plus-profile-pinning. They’re all answers to the same question: how do I get this external agent into the session that’s already open on the user’s screen? We wrote a longer breakdown of the three ways agents connect to your browser and what each one quietly costs you, and the connection step is where most of the cost lands.

Dassi skips the question. It’s a Chrome extension that lives in the side panel of the browser you’re already using. There’s no second browser to launch, no profile dropdown, no relay handshake to babysit. When you ask it to draft a reply in Gmail, it acts in the Gmail tab that’s open right next to it, under the account whose avatar is in the corner. The session is yours because it’s literally the same session.

That’s not a clever architecture. It’s the absence of one. The reason cloud agents and external relays keep tripping over login state is structural, and we got into the gory details in why cloud browser agents can’t see your tabs. An extension doesn’t have that gap to bridge, so there’s nothing to misconfigure.

So before you debug relay again

If you’re committed to OpenClaw and Browser Relay, the move is to pin the relay to the exact profile holding your logins and verify the avatar before every run that matters. Tedious, but it works once you know the trap is profiles and not the relay itself.

Or you stop putting a browser between you and the browser. Dassi is free on the Chrome Web Store, you can log in with your existing ChatGPT subscription or bring your own key, and the session question never comes up because there was only ever one session. The damn login screen stops showing up when the agent and your tab are the same thing.