Clem Delangue, the Hugging Face CEO, has been banging the drum lately that open-source and local AI matter more now than they ever did. I read one of his threads and kept circling back to a much smaller, dumber problem that makes his case better than any manifesto: my browser agent keeps losing its connection every time Chrome restarts.

Not a philosophical failure. A literal one. The damn thing just stops responding to a tab that, as far as it’s concerned, vanished.

The disconnect nobody warns you about

If you run a browser agent that drives your real Chrome through something like Browser Relay or a remote CDP link, you’ve almost certainly hit this. You kick off a task. Then the agent navigates to a new page, or you switch tabs mid-run, or Chrome quietly updates itself overnight and relaunches. And suddenly the agent is talking to a ghost. It spins, retries, and eventually reports a connection error for a session that was working sixty seconds ago.

Most tools present this as a flaky network blip. It usually isn’t.

Why the pipe snaps

The Chrome DevTools Protocol is the plumbing underneath almost every agent that “controls your browser.” When a remote or relay-based agent attaches to your tab, it grabs a specific target (the tab) and opens a session against it, identified by an id that Chrome hands out. That id is not permanent. When the tab navigates across origins, or the renderer process gets swapped out for a fresh one, or the tab is discarded to save memory, Chrome can tear down the old target and mint a new one. The agent is still clutching the old handle, which now points at nothing, so every command it sends falls into the void. Relay setups stack another failure surface on top: a local relay process bridges a websocket up to a cloud controller, and the moment that socket drops or the relay restarts, the cloud side has to reconnect, re-enumerate every target, re-identify which one is your tab, and rebuild the session from scratch before it can do a single thing. Every one of those hops is a fresh place for the whole chain to break, and a Chrome restart snaps all of them at once because the entire target list gets thrown away and rebuilt with new identifiers the remote side has never seen.

Profiles make it uglier. Because relay flows often route through a controlled or freshly-spawned Chrome profile, the session the agent reattaches to may not be the same profile you were logged into. So even when reattachment technically succeeds, you land in a browser that doesn’t know who you are.

Reattachment is the part that’s supposed to save you

Serious relay implementations try to reattach automatically. Poll for targets, match by URL, re-open the session, resume. When it works, you barely notice.

But reattachment is best-effort by design, and it leans on assumptions that a real browsing session violates constantly. It assumes your tab kept the same URL. It assumes the profile survived. It assumes the cloud controller and the local relay came back up in the right order. Break any one of those and the agent either fails loudly or, worse, silently reattaches to the wrong thing and keeps going.

I wrote a longer teardown of a nearly identical failure in why Claude Code’s Chrome extension keeps disconnecting, and the shape of the problem is the same everywhere: the more machinery sitting between the agent and the tab, the more ways that connection has to die.

A tab you already own doesn’t need reattaching

This is where the local-versus-cloud argument that Delangue keeps making stops being abstract. Dassi runs as a Chrome extension living in the browser’s side panel, so it isn’t holding a remote CDP socket to your tab at all. It reads and acts on the page you’re already looking at, through the browser’s own extension surface, using the session you’re already logged into. When you navigate, the extension is still right there. When you switch tabs, it follows you. And when Chrome restarts, the extension reloads with the browser, because it is part of the browser now.

There’s no relay to reconnect. No profile mismatch, because it’s your profile. No cloud controller waiting to re-enumerate targets it lost track of.

I won’t oversell it. A hard Chrome restart still wipes the in-progress state of a running task, so a half-finished multi-step job doesn’t magically resurrect itself, and you’ll restart that one by hand. But there’s a real difference between “the task ended and I’ll rerun it” and “the connection to my browser is fundamentally gone.” The first is a normal interruption. The second is architecture leaking into your afternoon.

Because the agent lives where your login already lives, the whole class of reattachment bugs just never gets a chance to happen. If you want to see the difference without reading another CDP diagram, Dassi is on the Chrome Web Store, and I broke down the three ways agents actually connect to your browser in this piece.

Delangue is worried about who owns the model weights. Fair. I’ve started caring just as much about who owns the socket to my tab, because that turns out to be the thing that quietly decides whether the agent works at 4pm on a Tuesday.