How to keep a terminal session running after you disconnect

Two very different problems hide behind the sentence "my session dropped". One is the network: the connection between your phone and your Mac broke. The other is the process: the program you were running was killed. The first is annoying and recoverable. The second loses forty minutes of work. Almost every tool on the market solves the first and quietly ignores the second, which is why people learn the difference the hard way.

The short answer, if you only read this far: run your long jobs inside tmux, which keeps your shell alive on the Mac independently of whatever you are connecting from. If you already have SSH working, install tmux and type tmux new -s work before anything else. If you are doing this from an iPhone or iPad, Servey - the app we make - opens every terminal session that way by default, so there is no second thing to remember and nothing to configure to reach the Mac in the first place.

The table also has a useful surprise in it. Screen mirroring, often dismissed as the slow and heavy option, is accidentally good at persistence: a Terminal window inside a mirrored desktop is just a window on the Mac, so nothing about your connection can kill it. Plain SSH, which people reach for because it is light and fast, is the one that loses the work.

Why does my SSH session die when I close the app?

Because the shell is a child of the connection, and when the connection goes the operating system tells everything under it to stop. Concretely: SSH gives you a pseudo-terminal, your shell runs attached to it, and the commands you type run as children of that shell. When the connection drops, the kernel sends a hangup signal, SIGHUP, down that tree. The default response to SIGHUP is to terminate. Your build gets the signal, does not handle it, and stops. The word is a literal holdover from modems physically hanging up, and the behaviour has never changed.

This is also why the half-fixes are half-fixes. Running a command with nohup, or backgrounding it with an ampersand and disown, does stop SIGHUP from killing it. But you have now given up the thing you actually wanted: you cannot see the output any more, you cannot answer a prompt, and you cannot get back in front of it. It is fine for a job that runs unattended and writes to a log. It is useless for a build that might ask a question, or an AI coding agent that stops halfway to confirm something.

What tmux actually does

tmux moves your shell out from under the connection. Instead of your shell being a child of SSH, tmux runs as its own long-lived process on the Mac, and your shell is a child of tmux. SSH then just attaches a view onto it. Kill the connection and you have killed a viewer, not the work. Reconnect later, attach again, and you are looking at the same session with the same scrollback and the same half-finished prompt waiting for an answer.

• tmux new -s build - start a named session called build.
• Ctrl-b then d - detach, leaving everything running.
• tmux ls - list the sessions currently alive on the machine.
• tmux attach -t build - reattach to it, from anywhere, later.
• tmux kill-session -t build - end it deliberately when you are done.

Name your sessions. The default names are numbers, and a list of numbers tells you nothing three days later. The other detail worth knowing is that tmux allows several clients to watch one session at once, which is what makes it possible to start something on an iPad and then walk to your desk and carry on from the Mac with the same output in front of you.

Why this is harder from an iPhone than it looks

Everything above assumes you can already reach the Mac and already have a working SSH setup. From a phone that is three separate problems, and each one has its own way of going wrong. You need an SSH client on iOS. You need your keys on the phone, which means either generating a key there and adding it to the Mac or moving a private key onto a device you carry in public. And you need the Mac to be reachable at all from outside your home network, which most people discover is the hard one.

That last problem is not really about SSH. A home router does not accept unsolicited inbound connections, your address changes, and a growing number of home connections sit behind carrier-grade NAT where no amount of port forwarding will help. The usual answers are a VPN, a mesh VPN such as Tailscale, or a tool that does NAT traversal for you - and none of them give you the persistence, which you still have to set up yourself once you arrive. There is an ergonomic problem too: Ctrl-b is the tmux prefix and an iPhone keyboard has no Control key, which is the most common reason people give up on tmux from a phone. Both halves are what we built around, and they are why persistent sessions are the default rather than a setting.

How Servey handles it

Servey makes persistence the default rather than something you opt into. Every terminal session you open is a named session that lives on the Mac, so there is no separate step to remember and nothing to configure. Close the app, lose signal, put the phone in your pocket, get on a plane: the work carries on. Open the app again and the session list shows what is still running, so you pick one and rejoin exactly where it got to. You can have the same session open on the Mac and the iPad at once, which is genuinely useful when you start something on the sofa and finish it at the desk.

The part worth knowing about, because it is unusual for a paid app to volunteer it, is that these are ordinary tmux sessions on your own machine. Servey shows you the attach command for each one, so you can paste it into Terminal.app, iTerm, Ghostty or an SSH connection and land in the same live session with the app not running at all. If you stop paying, or stop using it, or simply prefer a laptop that day, nothing you started is trapped. That also means the tmux knowledge above is not wasted if you later move on.

Reachability is handled in the same app: Servey connects on your local network directly, and from outside it establishes a private peer-to-peer connection between your own devices, including on carrier-grade NAT, with no VPN and no port forwarding. And because a terminal sits one tap from the mirrored screen, the case that defeats a pure SSH setup - a dialog box only the GUI can dismiss - does not strand you.

The honest limits: Servey is Apple-only and cannot reach a Windows or Linux host, it needs macOS 15.3 on the Mac and iOS or iPadOS 18.5 on the device you control it from, and it launches soon rather than today. If you need a working setup this afternoon, do not wait for us.

What to use if you need this working today

Install tmux on the Mac with Homebrew, then pick an iOS terminal app - Termius and Blink Shell are both good, and Blink in particular has a well-designed key row that makes the Ctrl-b prefix bearable. Add Tailscale on both ends if you cannot reach the Mac from outside. That combination gives you the persistence and the reachability today, for the price of setting up three things instead of one, and it is what we would tell a friend to do this week.

One last habit that costs nothing: get into the reflex of typing tmux new -s something the moment you connect, before you run anything long. Persistence you remembered to turn on after the build started is not persistence.