Durable AI agent sessions: how tmux + automatic reconnect survive a dropped connection

You kick off an agent on a long task, close your laptop, ride the train home, open it again — and the session is right where you left it. That "it just came back" feeling is one of the best things about dev-mux. This post explains, honestly, *how* it works — because the mechanism matters, and because a common way of explaining it (the "mosh myth") gets it wrong.

What "durable" actually means here

A durable AI agent session is one that outlives your client's connection. Your agent keeps running, its terminal state is preserved, and any surface you reconnect with picks up exactly where things are — even after a Wi-Fi switch, a laptop sleep, a lost tunnel, or a full app restart.

Two ingredients make that true in dev-mux, and neither of them is magic:

1. The session lives on the hub, in tmux

Your terminal sessions don't live in your browser tab or your phone app — they live in tmux on the hub, the small per-tenant coordinator VM. tmux is the boring, battle- tested tool that has kept terminal sessions alive across disconnects for decades. Your client is just a window onto a session that's already persistent server-side. Close the window and the session keeps running; the agent doesn't even notice you left.

2. Every surface reconnects automatically

The second half is client-side: the web cockpit and the other surfaces reconnect automatically when the network blips. If a socket drops, the client notices, backs off, and re-establishes the stream to the same tmux session — you don't refresh, you don't lose your place, you don't restart the agent. The felt result is a session that simply doesn't break.

Put together, that's the one honest one-liner we use everywhere:

> tmux-backed sessions with automatic reconnect.

Correcting the "mosh myth"

You may have seen the outdated myth that "mosh + tmux keeps your sessions alive." It's a tempting story — mosh is a clever tool — but for dev-mux it's not accurate, so we've retired that copy.

Here's the real picture:

• Durability comes from tmux on the hub plus client-side automatic reconnect. That

is the mechanism. Full stop.

• mosh is not the durability mechanism. Where it happens to be installed it can be

a nice interactive-attach convenience, but it is not what keeps your sessions alive, and the web cockpit and mobile surfaces don't rely on it at all.

We'd rather be precise than sound clever. If someone tells you dev-mux is "mosh- durable," that's outdated — the accurate phrase is tmux-backed sessions with automatic reconnect.

Why the hub-side model is the right one

Keeping the session on the hub instead of on your device buys you more than crash recovery:

• Switch surfaces freely. Start in the web cockpit, glance at it later on your

phone, check status on HUD glasses — same live session, because the session isn't tied to any one client.

• Long tasks keep going. An agent chewing through a refactor doesn't stop because

you closed a lid or lost signal.

• Reconnect is cheap and automatic. No manual re-attach ritual; the client does it.

And it does all this without changing where your code runs: your code never leaves your machines. The hub relays terminal sessions to the machines you own; it doesn't execute your workloads and it doesn't store your source at rest. Durable sessions and the zero-code moat are the same architecture seen from two angles — the hub coordinates, your machines do the work.

The takeaway

Durable AI agent sessions in dev-mux aren't a trick and they aren't mosh — they're tmux on the hub plus automatic reconnect on every surface. Close the lid, switch networks, reopen anywhere: your fleet is right where you left it, still running on your own machines.

---

*Curious why the agents run on your machines in the first place? See the companion post on running AI coding agents on your own machines.*