Why Your Browser Relay Drops the Moment You Navigate or Restart Chrome
I keep running into the same complaint in OpenClaw threads on GitHub: someone finally gets Browser Relay connected, runs one task, clicks a link, and the whole thing goes dark. Agent stops responding. They restart Chrome to fix it and now it won’t reconnect at all. Then a reinstall, a new token, a fresh profile, and the loop starts over.
So let me explain what’s actually going on, because this isn’t a bug waiting for a patch. It’s the shape of the thing.
The agent isn’t in your browser. It’s renting a phone line into it.
Browser Relay works by exposing Chrome’s DevTools Protocol, CDP, and letting a remote agent dial into it through a relay server. The agent runs somewhere else. A VPS, a container, a cloud box that you may or may not control. It reaches across the network into your local Chrome through that single CDP connection and steers the page from a distance.
That connection is the entire relationship. The agent has no body inside your browser. It has a wire running to it, and the wire is doing all the work.
Wires come loose.
Navigation tears down the room the agent was standing in
Here’s the mechanical reason, and it’s worth getting right because most of the “fixes” people try are aimed at the wrong layer. CDP doesn’t attach to “your browser” in some abstract sense. It attaches to a specific target, and a target is basically a page context living inside a tab. When you do a real navigation, a full document load rather than a single-page-app route swap, Chrome can throw away the old execution context and construct a brand new one for the incoming page, which means every reference the agent was holding, the frame, the DOM nodes, the session it bound to, points at something that no longer exists.
The relay sometimes catches this and re-attaches. Often it doesn’t, or it re-attaches to a stale target and silently does nothing. The agent isn’t confused about your intent. It’s standing in a room that got demolished while it was mid-sentence.
And restart is just the brutal version of the same event. Quit Chrome and every target dies at once, the debugging endpoint the relay was pointed at vanishes, and when Chrome comes back it spins up on a different port or refuses the remote-debugging handshake entirely unless you relaunched it with the exact same flags. So the relay dials the old number, gets nothing, and reports a connection it can’t establish. People read that as “the tool broke.” The tool didn’t break. The address changed.
This is the same family of failure I dug into when Claude Code’s Chrome extension kept disconnecting. Different product, identical root cause: an external process leaning on a debug socket it doesn’t own.
The login problem nobody mentions until it bites
There’s a second cost that’s quieter and, honestly, more annoying. Because the agent connects over CDP from outside, your authenticated state is fragile in ways you don’t notice until a task fails halfway.
You log into Gmail in your normal Chrome. The relay sometimes drives that real profile, sometimes spins up a separate debugging context that doesn’t share your cookies. So the agent lands on a login wall, or worse, trips a security check because the session looks like it’s being poked at from a strange place. You re-authenticate. You restart. The socket drops again.
A side-panel agent doesn’t have this problem, and the reason is boring
Dassi runs as a Chrome extension. The agent lives in the side panel, inside the same browser, on the same session you’re already using. There’s no relay, no remote CDP socket, no server holding the only copy of the connection.
So when you navigate, nothing tears down a remote attachment, because there wasn’t one. The extension is part of the browser’s own lifecycle. It sees the new page the way the rest of your browser does. When you restart Chrome, the extension comes back with it, still scoped to your logged-in profile, because that’s where it lived the entire time. Your authenticated tabs are just your tabs.
This is the whole argument for browser-native execution over the rented-socket model, and I’ve made the longer version of it here. An agent that borrows a connection inherits every fragility of that connection. An agent that runs where the work happens inherits the browser’s own resilience instead.
So if your relay keeps dropping
You can chase it. Pin the debug port, relaunch with fixed flags, write a reconnect wrapper, babysit the token. People do, and some get it stable enough. But you’re hardening a connection that was never meant to outlive a page load, and every Chrome update is a fresh chance for it to break again.
Or you skip the wire. Dassi is free, in the Chrome Web Store, and runs on your own model key or your existing ChatGPT login. Navigate all you want. Restart whenever. The agent’s still there, because it never left the building.