Getting started with TermLink: sign in, register a machine, connect

TermLink gives you a live terminal on a machine you own, from anywhere else — a browser, your phone, or another terminal. There is no SSH key to distribute, no port to open on your router, and no VPN to dial into.

This post walks the whole path: sign in, register a machine, connect to it, and run something.

What you need

The termlink binary on any machine you want to reach (macOS, Linux, or Windows).
A Google account. That is the whole credential story — TermLink has no passwords, no PINs, and no keys for you to manage.

Step 1 — Sign in

On the machine you want to reach, run:

termlink login

Your browser opens, you sign in with Google, and the credentials are stored locally on that machine and refreshed automatically. You do this once per machine — not once per session.

Nothing about this step opens a port or exposes the machine. It just tells TermLink which account this machine belongs to.

Step 2 — Register the machine as a host

Still on that machine:

termlink host

The machine registers under your Google account and dials out to the TermLink relay. That direction matters: because the connection is outbound, the machine works fine behind a home router, a NAT, or a corporate firewall, and it never accepts an inbound connection. There is nothing listening for an attacker to find.

Leave this running. It is the process that owns your session.

Step 3 — Connect from somewhere else

From any other machine:

termlink client

You get a numbered list of the machines registered to your account. Pick a number, and you are in that machine's shell.

Only your own machines appear — the host list is scoped to the Google account in your token, so you never see anyone else's machines and they never see yours.

Step 4 — It is a real shell, not a screenshot

Here is a Mac being reached from a Windows box. The window at the back is the Mac itself; the one in front is TermLink on Windows, connected to it. Watch ls run:

Running ls on a remote Mac through TermLink from a Windows terminal — Left: the actual Mac, shown over Chrome Remote Desktop purely as a witness — so you can see the same shell on both sides. You do not need Chrome Remote Desktop to use TermLink; the window in front is all you need.

The output is identical on both sides because it is the same shell. TermLink is not streaming a picture of a desktop — it is relaying the terminal itself, byte for byte.

That distinction is why it stays usable on a bad connection and on a phone screen, and why cat, a log tail, or a full-screen terminal UI all behave the way they would locally:

Running cat on a remote machine through TermLink — cat on the remote machine, rendered in the TermLink client.

Or skip the CLI entirely

You do not need termlink client on the machine you connect from. Open the web client, sign in with the same Google account, and your hosts are waiting in a list. That works from a laptop you have never installed anything on — or from your phone.

What this replaces

If today you would reach for SSH, you have to expose a port and manage keys. If you would reach for Chrome Remote Desktop or TeamViewer, you have to stream an entire desktop and keep the far machine unlocked with a session running.

TermLink mirrors the one window you actually care about — the terminal — and authenticates it with the Google account you already have.

Now that you can reach a machine, the interesting part is what you leave running on it. See Running Claude Code on a remote machine — start an agent on your workstation, close the laptop, and check on it from your phone.