Clément Delangue, Hugging Face’s CEO, said something last week that stuck with me: companies are “done renting their AI.” He meant models, the shift from calling someone else’s API to running weights you actually control. But the same word, renting, describes what a Browser Relay is. You’re renting a connection to a browser you already own.

And rented connections drop.

The relay is a wire clipped onto the outside of Chrome

Browser Relay and remote-CDP setups work by launching Chrome with a debugging port, then talking to it over the Chrome DevTools Protocol from some other process: a local agent, a VPS, a cloud runner. The browser doesn’t know it’s being driven. Something outside reaches in through a port and pretends to be a debugger.

That wire is the whole problem. CDP attaches to a specific target, a tab or a frame or an execution context with an ID. When you navigate to a new page, Chrome destroys the old execution context and builds a fresh one. The target ID your relay was holding is now pointing at nothing. The socket can stay happily open while the thing on the other end talks to a ghost.

Because navigation is a demolition, not a redecoration.

When Chrome loads a new document it tears down the JavaScript execution context, invalidates the old frame tree, and fires a burst of protocol events (Target.targetDestroyed, Page.frameNavigated, a fresh context created), and if your relay isn’t carefully re-attaching to the new target on every one of those transitions, it ends up gripping a handle to a page that no longer exists. Most relay setups do re-attach. Some do it a beat too late. All of them have a window, mid-navigation, where a command you send just falls on the floor.

Single-page apps make this weirder. A lot of “navigation” in a SPA doesn’t destroy the context at all, so your relay survives, right up until one route does a hard reload and it doesn’t.

Restart is worse

Quit Chrome, reopen it, and the debugging port comes back on the same number. Feels like nothing changed. It did.

The new Chrome process has a new set of targets, new context IDs, and, depending on how it got relaunched, sometimes no debugging port at all, because the relaunch came from the taskbar instead of the flagged command that opened the port in the first place. Your agent reconnects to a port that either isn’t listening, or is listening to a completely different browser session than the one you were logged into. Same window on your screen. Different browser underneath.

The troubleshooting loop everyone runs

You know the one. Connection drops. You check the port. You confirm Chrome is running with --remote-debugging-port. You bounce the relay process. It reconnects. You navigate. It drops again. So you start reading GitHub issues at 1am.

I dug into a near-identical version of this with Claude Code’s extension a while back (/blog/why-claude-code-chrome-extension-keeps-disconnecting/), and the root cause rhymes: a connection maintained from outside the browser has to survive every single thing the browser does to itself. Navigation. Restart. Profile switches. A Chrome update that quietly recycles the renderer. Each of those is a fresh chance for the wire to shake loose.

You can harden it, of course. Auto-reconnect logic, target re-attachment on every frame event, health-check pings every few seconds. People build all of it. It works most of the time, which is a genuinely damning thing to say out loud about the setup handling your email.

What has no relay to drop

The part that took me embarrassingly long to internalize: the disconnect isn’t a bug in any particular relay implementation. It’s the cost of the relay existing at all. You cannot lose a connection you never made.

Dassi is a Chrome extension. It runs inside the browser, in the side panel, in the same tab you’re already sitting in and already logged into. There’s no external process clutching a CDP handle, no port to reconnect to. When you navigate, the extension navigates with you, because it lives in the page context Chrome is rebuilding rather than watching that context from across a socket. When you restart Chrome, the extension is simply there when Chrome comes back, the way your bookmarks are there. Nothing reconnects because nothing ever disconnected. The agent isn’t a debugger reaching in from outside. It’s a resident.

This is Delangue’s argument aimed at a different layer of the stack. Renting is fine until the thing you’re renting is load-bearing, and a live connection to your logged-in browser is about as load-bearing as it gets. I’ve written before about why cloud setups can’t see your session at all (/blog/cloud-browser-agents-cant-see-your-tabs/), and the relay problem is that idea’s messier cousin: they can see your tab, briefly, until they can’t.

So if you’re sick of the 1am issue-thread ritual, Dassi lives in the tab and skips the entire category. It’s free, it’s on the Chrome Web Store (https://chromewebstore.google.com/detail/dassi-ai-browser-agent/bjcngahpcjeililljmfegmlanlpgibdi), and it runs on the login you already have.

Anyway. My relay dropped again halfway through writing this. Felt on-brand.