tmate alternative: for your own sessions, not pairing

If you want to show a colleague your terminal for the next ten minutes — pair on a bug, walk someone through a deploy, get a second pair of eyes on a stack trace — tmate is the right tool and you should stop reading this and go run tmate. It is free, it is one command, and nothing here beats it at that specific job. This post is for the different question: reaching your own sessions, continuously, from your own devices, which is a job tmate wasn't built for and doesn't claim to be.

What tmate is actually best at#

tmate forks a second tmux server purpose-built for sharing and hands you both an SSH command and a web link in the same second you run it:

$ tmate
tmate identifies remote session as 3f8a2c1e...
ssh session: ssh [email protected]
ssh session read only: ssh [email protected]
web session read only: https://tmate.io/t/ro-3f8a2c1e

Anyone with the SSH link is typing in your terminal in the time it takes to paste a command. No account for them to make, no inbound port on your machine, no reverse proxy to configure. That's the entire value proposition and it's a genuinely good one: for incident response, live teaching, and quick pairing, tmate removes every step between "I want to share this" and "someone else is looking at it." It's open source, self-hostable if you want your own relay instead of tmate's public one, and it has been the default answer to "how do I share a terminal" for a reason.

Where the job is different#

The friction shows up the moment the thing you want isn't a shared moment but a session you keep. tmate's model is a new, ephemeral, purpose-built session — not a window into the tmux server you already run with your actual work in it. Three consequences follow from that:

• It's a different session, not yours. tmate forks its own tmux server. Your existing panes — the ones with your agents, your dev servers, your actual context — aren't in it. You'd have to reproduce your layout inside the tmate session, or attach your real session from inside it, which works but is an extra step every time.
• It ends when you exit. There's no "come back tomorrow" — the session and its link are tied to that tmate process. That's correct behavior for its job; it's the wrong shape for checking on a long-running build from your phone at 11pm.
• The web link is read-only, and desktop-shaped. It's built for watching, not for typing on a touchscreen. There's no on-screen prefix key, no touch-adapted layout — reasonable, because tmate's web view was never meant to be someone's primary interface, just a quick look.

None of that is a flaw in tmate. It's evidence the tool was built for a narrower, well-defined job and doesn't try to be everything. The mismatch only appears when you reach for it to do the other job — your own long-running sessions, revisited over days, from a phone, with some idea of whether they're still making progress.

The comparison in one line#

tmate answers "how do I show someone my terminal right now." mtmux answers "how do I check on my own terminal from somewhere else, later, and know if it needs me." They can both be the correct tool in the same week, for different afternoons — this isn't an either/or so much as two answers to two different questions that happen to both involve tmux.

If the actual need is watching a long agent run — a Claude Code refactor, a Codex CLI migration — rather than sharing a session with a person, the relevant distinction isn't tmate vs. anything. It's whether you're getting told which of four things happened while you were away, covered in stop babysitting coding agents. And if browser access specifically is the requirement, tmux in a browser runs through ttyd, wetty, and purpose-built clients side by side with the actual setup for each.

When tmate is still the right call, full stop#

• You want to hand someone temporary, revocable access to a terminal for a single session — nothing here beats the one-command setup.
• You're doing incident response and need a stranger from another team looking at your screen in the next thirty seconds.
• You want to self-host your own sharing relay instead of trusting anyone else's — tmate's server component is open source and built for exactly that.
• You don't want a persistent session at all — for a one-off, "it ends when I close it" is a feature, not a limitation.

Full trade-offs for the wider set of options — SSH apps, VS Code Remote, browser clients — are on the comparison page; the security page covers how the zero-knowledge relay and per-device revocation work for the continuous-access side of things.