
There are two usual ways to Remote Desktop into a machine that isn't on your LAN, and both are bad in their own way.

The first is to **forward port 3389** on the router and connect to the public IP. It works, and it's also how a huge share of ransomware gets in — an exposed RDP port is a doormat that every scanner on the internet is already knocking on. The second is to **stand up a VPN** first, which is more work, more to maintain, and usually gives the remote device far more of your network than "I just want to reach that one PC."

Reach RDP is a third way: your **existing** Remote Desktop client connects to the remote machine over an **identity-gated tunnel**, with **nothing exposed** and **nothing forwarded**.

## What it looks like

The remote machine turns on "Share this PC," which advertises its RDP service (port 3389) to your TYO ID — or to a teammate you've explicitly shared it with. From the other end you pick that machine and Reach does two things: it stands up a **local forward** (a listener on `127.0.0.1`) and launches your normal RDP client at it. To mstsc / Microsoft Remote Desktop / Remmina, it looks exactly like connecting to a machine on your own desk. The bytes, meanwhile, are travelling through Reach's tunnel to a box that could be behind NAT, behind CGNAT, or in another country entirely.

No inbound firewall rule. No public 3389. No static IP. The remote machine makes an **outbound** control connection to Reach and waits; your connection is matched to it by **identity**, not by address.

## How the bytes travel

Same substrate as the rest of Reach. If your device and the target are on the **same subnet**, the connection goes **peer-to-peer, directly**, and the gateway never sees your pixels. Otherwise it rides the **gateway relay**. Either way the RDP stream is tunnelled raw, with a couple of deliberate tunings — `TCP_NODELAY` and interactive PDUs flushed immediately — because the thing that makes tunnelled RDP feel awful is buffering keystrokes and mouse movement, and we don't.

## The security posture, and the sharp edges we filed down

RDP is fiddly, and getting it to tunnel *cleanly* took solving some genuinely annoying failure modes. A few worth naming, because they're the difference between "works" and "works reliably":

- **NLA stays on.** The tunnel doesn't weaken authentication — CredSSP / Network Level Authentication is preserved (`authentication level:i:2`). Reach moves bytes; it doesn't stand between you and the server's auth.
- **A forced, fresh credential prompt.** Because every Reach target shares `127.0.0.1` on your machine, mstsc would happily reuse a credential it cached against that address from a *different* box — connect to a domain-joined machine, then a workgroup one, and it tries Kerberos against a KDC it can't reach and dies before you even see a prompt (`0x80090311`). Reach's generated `.rdp` forces the prompt so you enter *that* machine's own credentials.
- **An old-server quirk (`HYBRID_EX`).** Some older RDP servers reset the connection if the client advertises `PROTOCOL_HYBRID_EX`; Reach can strip it from the X.224 request for exactly those hosts (off by default, because modern Windows needs it kept).
- **Secure mode.** For locked-down access you can strip the clipboard, drive and USB redirection virtual channels, so a session is view-and-control only with no data bridge back to the host.

## Multi-monitor, and other client features

Because Reach tunnels the raw RDP stream, **multi-monitor works out of the box**. Reach's generated `.rdp` now sets `use multiple monitors:i:1`, so a full-screen session spans all your displays as if the box were on your desk — it's a no-op on a single monitor, and windowed mode still behaves normally. Same story for other RDP features: they're between your client and the host, and Reach is transparent to them.

## What it isn't

- **It's a transport, not an RDP server.** You still need a remote machine actually running Remote Desktop (a Pro/Enterprise/Server edition — Windows Home doesn't host RDP, and multimon needs a non-Home edition too).
- **Secure mode is a trade.** Stripping clipboard/drive/USB is the point when you want it, and an annoyance when you forget it's on — it's per-forward, so you choose.

The headline, though, is the one that matters for anyone who's ever port-forwarded 3389 and then watched the failed-login counter climb: you can have Remote Desktop to any of your machines, from anywhere, using the client you already use — and leave **nothing** listening on the public internet.


64c7f93b941b7ab774d8eb14aa6df0908573ad4fc3414704be79c6920920d339

How TYO Reach carries RDP — an identity-gated tunnel to a remote Windows machine with no port-forwarding and no exposed 3389, P2P-or-relay transport, NLA preserved, a forced fresh credential prompt, an optional secure mode that strips clipboard/drive/USB, and transparent multi-monitor passthrough.

Remote Desktop usually means either exposing port 3389 to the internet (the number-one ransomware doormat) or standing up a VPN. Reach RDP does neither — it tunnels your existing Remote Desktop client to the machine over an identity-gated path, so nothing is exposed and nothing is forwarded.

Reach RDP: remote desktop without opening a hole in your network


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.


f73f36dcc146aa2fe0b1ec3d15847255de93cc6c7b8cb08d12301e321aea5f57

How TYO Reach Sessions works — a persistent terminal on a host, attachable from any device over the ZTNA transport via a new `term` protocol, backed by a native PTY/ConPTY broker or a tmux delegate, with P2P-or-relay transport and cross-gateway discovery.

Most remote-access tools hand you a connection to a machine. Reach Sessions hands you the live session itself — a terminal that lives on a host and that any of your devices can attach to, detach from, and pick back up exactly where you left it.

Tag: Ztna

Tag: Ztna

Reach RDP: remote desktop without opening a hole in your network

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