TermLink vs SSH, tmux, and remote desktop

You have Claude Code running on a machine that is not the one in front of you. There are four common ways to get to it. They are not interchangeable, and the differences show up exactly when you are away from your desk with a phone in your hand.

SSH

SSH gets you a real shell, which is the right primitive. The cost is everything around it: something has to be listening on that machine, which means a port open to the network, a key distributed to every device you might want to connect from, and — if the machine sits behind a home router or a corporate firewall — a tunnel, a VPN, or a port forward to punch through.

Then you do it from a phone, and you meet the second problem. An SSH client on a touchscreen has no Esc key, no Ctrl, no arrows. Claude Code's terminal UI needs all four.

TermLink instead: the host dials out to the relay. Nothing listens, so there is no inbound port to expose and nothing for a scanner to find, and it works from behind NAT without configuration. Your credential is the Google account you already have — no keys to distribute, because there is nothing to distribute them to.

tmux

tmux solves a different problem, and solves it well: the session survives after you detach. Your process keeps running even when nothing is attached to it.

TermLink does not do that, and it is worth saying plainly. TermLink is not a background daemon. The termlink host process owns the session, and if that process stops, the session stops. If what you want is a shell that outlives every client on the machine, you want tmux — and you can run tmux inside TermLink perfectly well.

What TermLink adds that tmux does not have:

• A browser and phone client. tmux still assumes you have a terminal emulator and a way in — it does not solve reaching the machine, only staying attached once you are there.
• A correct repaint of Claude Code's full-screen TUI when you reconnect, in a browser.
• Several machines in one list, each card showing that agent's latest message.
• Auto-Yes for permission prompts.

They are complements, not rivals. tmux keeps the process alive; TermLink is how you reach it from a train.

Chrome Remote Desktop, TeamViewer, VNC

The remote desktop family streams an entire screen. That has three costs that all land at once when your agent is what you are checking on:

1. It is heavy. You are pushing video for a window that contains a few kilobytes of text. On a weak connection it degrades into an unreadable smear — and text is the one thing that has to stay legible.
2. It is clumsy on a phone. You are panning and pinching around a desktop designed for a 27-inch monitor to read one terminal window.
3. The far machine has to be unlocked, with a desktop session running. A headless box that exists only to run agents does not have one.

TermLink instead: it mirrors only the terminal your agent lives in — the one window you actually came for. It is text, so it is light enough for a phone browser and it survives a flaky connection. The machine never accepts an inbound connection, so there is no exposed port and no desktop for anyone to hijack. And it works fine on a headless server, because there is no screen involved.

Side by side

	Reaches a headless box	Works on a phone	Survives detach	Inbound port
SSH	yes	painfully	with tmux	yes — exposed
tmux	n/a (local)	n/a	yes	n/a
Remote desktop	no	badly	yes	usually
TermLink	yes	yes	no — host must stay running	none

The short version

If you want a process that outlives everything, use tmux. If you want a desktop, use remote desktop. If you want to reach the terminal your agent is running in — from a browser, from a phone, from a machine you have never configured — that is the case TermLink is built for, and it gives up the daemon to get there.

---

Set it up in about two minutes: getting started with TermLink.