Reach Sessions: your terminal follows you, not the other way arounderic

Here's a small moment that turns out to be the whole point.

You start a long task in a terminal on your office machine — a build, a data migration, a coding agent chewing through a refactor. Then you step away from that desk. And "away" takes a dozen shapes:

• some days you knock off and pick it up from the couch at home;
• some weeks you're barely at a desk at all — you're always on the move, hopping between a desktop at work, a laptop on the road, and a phone or tablet in between;
• you're at a client's office running a demo, and you need the thing you left running back at base;
• you're between meetings — on the train, in a café, killing time at an airport gate — with ten minutes to check on a job;
• or you simply switched machines mid-thought and don't want to lose your place.

Whichever it is, you open a different device. And instead of SSHing in to a fresh shell and squinting at log files to reconstruct what happened, the same session is right there: the scrollback, the running process, the cursor blinking where you left it. You didn't reconnect to the machine. You picked the session back up.

That's Reach Sessions. The insight behind it is that the thing people actually want from remote access isn't connectivity — it's continuity. Connectivity ("I can reach that box") is table stakes. Continuity ("my work follows me") is the part that feels like magic the first time. Reach already owns the connectivity substrate; Sessions is the layer that turns a device-bound remote desktop into a session that roams with you.

What it actually is

A Reach Session is a persistent terminal that lives on a host. Any device you own can attach to its live state — full scrollback plus the live stream — and detach again without killing anything. Close the lid, reattach from your phone an hour later, it's all still there.

It rides Reach's existing Zero-Trust transport unchanged, as a new target protocol we call term (alongside rdp/vnc/ssh). The gateway doesn't need to understand terminals — it's a byte-agnostic relay — so adding Sessions didn't mean re-plumbing the network. It meant adding a small broker on the host and a thin attach client.

The broker: native PTY, or your existing tmux

On the host, one Broker interface has two implementations:

• Native PTY mux (the default) — a real pseudo-terminal per session: creack/pty on Linux and macOS, ConPTY on Windows. No dependencies, works everywhere.
• tmux delegate (Unix, when tmux is on the PATH) — instead of spawning fresh shells, Reach exposes your existing tmux sessions. Run your work in tmux new -s build, and that session is now attachable from any of your devices. This is the one that tends to click for people: tmux already gives you persistence on the box; Reach gives you persistence across boxes.

Starting a host is one command — reach host — or a toggle in the desktop tray ("Host sessions on this PC"). From another device you list what's available with reach sessions and attach with reach connect <host> <session> (or reach attach). Detach with Ctrl-]; the session keeps running on the host.

How the bytes get there: P2P first, relay always

When you attach, Reach tries the fast path first: if your device and the host are on the same subnet, it connects directly, peer-to-peer, and the gateway never touches your data. If they're not — different networks, a laptop on a hotspot, a box in another city — it falls back to the gateway relay. Either way the session is addressed by identity + target, not by IP: your own devices are discoverable to each other automatically (same owner, no sharing step), and reaching someone else's host requires an explicit share.

A detail we recently made seamless: discovery and dialling now work regardless of which gateway each device happens to be connected to. Your laptop can be on the closest gateway in one region and the host on another; Reach resolves where the host actually lives and routes the setup there, while your data path stays on the gateway you can actually reach. (That last part matters a lot in networks where only some endpoints are reachable — more on that in a future post about Reach in China.)

The part we're most interested in: driving agents

Because a Session is just a terminal, you can put anything in it — including an AI coding agent. Run Claude Code (or any agent) inside tmux new -s agent, and now that agent's session is a first-class Reach target. Attach to it from your laptop, glance at it from a second machine, and — the direction we're building toward — steer it from your phone: approve a tool call, nudge it, read where it got stuck, all from a device that was never going to run the agent itself.

That reframes the mental model. The agent doesn't live on "a server you SSH into." It lives in a session, and the session is reachable by identity from wherever you are. The phone becomes a controller for long-running work, not a tiny window onto a desktop.

Honest limits (for now)

We'd rather tell you where the edges are:

• It's a raw terminal stream, not a structured API. An external program can drive a Session (the attach client is a plain stdin/stdout bridge, so it pipes fine), but it gets exactly what a human sees — ANSI and all. A clean, framed "run this, give me stdout + exit code" mode for agents is on the roadmap, not shipped.
• One role per box at a time: in the current slice a machine is either sharing its desktop or hosting sessions, not both simultaneously. Both-at-once is a later enhancement.
• Mobile is a controller, not yet the full picture: the phone-steers-your-agent loop is where we're heading; today the solid, shipping surface is the desktop tray and the reach CLI.

None of that changes the core, which is already real and in daily use: a terminal that lives on a host, attachable from any device, that picks up exactly where you left it. Start it with reach host, attach with reach connect, and the next time you move between machines, your work comes with you.