How it works

What travels between your phone and your Mac, which way it goes, and what anything in the middle can see.

Text, not pixels

A remote desktop sends a picture of a screen. Tilde sends what the shell writes — the same bytes a terminal receives, escape sequences and all — and the phone draws the screen itself.

That choice decides almost everything else. An hour of work is about a megabyte instead of two gigabytes, the text stays sharp at any size, and it can be selected and searched because it is text. It also means the Mac has no picture to send: when a connection is lost and comes back, what gets replayed is the stream, not a screenshot.

Pairing happens once

Your Mac shows a code. It contains a public key, a single-use token and where to find the machine. Scanning it runs a handshake that only completes if both sides saw the same token — someone who reaches the network but not the screen cannot finish it.

Then the Mac asks a person to approve the device by fingerprint. A handshake proves a key; only you can say the key belongs to your phone.

On the same network

Your phone draws the screen Your Mac runs the shell 1 · finds it by name, over Bonjour 2 · encrypted, directly, nothing in between no server is involved at any point
The phone looks for the agent on the local network and connects straight to it. No part of this passes through anything of ours.

Anywhere else

Away from home, neither side can call the other: both sit behind routers that accept no incoming connections. So both make an outgoing one instead, to a rendezvous that introduces them and then copies bytes between the two.

Your phone on mobile data Rendezvous room id only carries ciphertext Your Mac at home or at work outgoing outgoing the keys are here, at both ends, and nowhere else no open ports · no VPN · no fixed address
Both sides dial out, so neither needs to be reachable. The rendezvous never holds the keys, so it moves bytes it cannot read.

What each part can see

SeesCannot see
Rendezvous An opaque room identifier, how much data passed, and the network addresses of two connections. Commands, output, file names, your machine's name, or which device is on the other end.
Your network That a connection exists. Anything inside it.
Us Nothing. There are no accounts and no analytics. —

The app tells you which path a session took, because latency and reachability both depend on it.

When the connection drops

A phone changing from Wi-Fi to mobile data loses its connection, and a session that died with it would take the work along — a build, a long command, an agent halfway through a task.

Your Mac terminal keeps running output kept, byte by byte Your phone out of signal then back again connection gone “I got this far” → everything after it
The phone says how much it had seen, and receives the rest. If the gap was larger than the agent could hold, the screen is cleared instead of continued from the middle of an escape sequence.

Restarting the agent is a different matter: that ends every session. Work inside tmux or zellij survives it, which is the main reason to keep long-running things in one.

Where the terminal actually lives

The part that interprets escape sequences and keeps the grid of characters — the terminal emulator — runs on the phone, not on the Mac. The agent only moves bytes between a pseudo terminal and the network.

This is why the text is crisp: the phone renders characters with its own fonts at its own resolution, rather than scaling someone else's picture. It is also why a reconnect replays a stream instead of a screenshot, and why the same core can serve a second kind of app without the agent knowing anything about it.