Why the process dies in the first place
Terminal AI agents are ordinary child processes of your shell. That single fact explains almost every dead session. Three killers, in order of how often they get blamed on the agent:
- You closed the terminal. When a terminal window closes, the kernel sends SIGHUP (hangup) to every process in that session. The agent receives it and exits mid-task. This is 50 year old Unix behavior, not a bug in the agent.
- Your SSH connection dropped. If the agent runs on a remote box over SSH, a dropped connection tears down the remote shell, which sends the same SIGHUP to the agent. Flaky wifi, a VPN hiccup, or your ISP renegotiating is enough.
- Your laptop went to sleep. Close the lid and the OS suspends every process on the machine. Nothing is killed, but nothing runs either. A 6 hour overnight task makes zero progress, and any open network connections (including the agent's API calls) usually die during the suspend anyway.
Which killer you have determines which fix you need. SIGHUP problems (closed terminal, dropped SSH) are solved by detaching the process from your session: tmux, screen, nohup, or systemd. Sleep problems are not. No multiplexer can make a suspended CPU execute instructions. For sleep, you either keep the machine awake or move the agent to a machine that never sleeps.
Quick diagnosis: if you want to check whether your current setup would survive, run the agent survival check. It walks the same failure modes this article covers and tells you which one will get you.
tmux and screen in 90 seconds
tmux is a terminal multiplexer. It runs your shell session inside a server process on the machine, so the session survives even when your terminal window or SSH connection goes away. This is the standard fix for SIGHUP:
Close the window, lose the SSH connection, reconnect from your phone. The agent never noticed. You reattach and the full scrollback is there.
screen is the older tool that does the same job:
Pick tmux if you are choosing today. It has panes, better scripting, and active development. screen's one advantage is that it ships preinstalled on more minimal distros.
The limit of both tools, stated plainly: tmux on your laptop does not survive sleep. It protects the session from disconnects, not the machine from suspending. tmux only earns its keep on a machine that stays awake.
nohup and systemd for real persistence
If you do not need to interact with the agent, you do not need a live session at all. Most CLI agents have a headless or print mode that takes a prompt, works, and exits. nohup makes that run immune to SIGHUP:
nohup detaches the process from the terminal, so logging out or closing the window does nothing to it. The tradeoff is that you cannot steer. There is no reattaching, no answering a question the agent asks. It is fire and forget, which is fine for exactly the tasks that are fire and forget.
For an agent that should always be running (a Discord bot, a monitoring agent, a long-lived Hermes style assistant), the correct tool on Linux is a systemd service, because systemd also restarts the process when it crashes:
Restart=always is the line that separates this from tmux. tmux keeps a session open; systemd keeps a process alive. If the agent segfaults at 3am, systemd starts it again 5 seconds later.
Mac-specific fixes: caffeinate, pmset, Amphetamine
On a Mac, the usual killer is sleep, and macOS gives you real tools for it:
caffeinate -i prevents idle sleep while the wrapped command runs. It is the cleanest overnight fix on a Mac that stays plugged in and open.
Two more levels if you need them:
- pmset changes power settings system wide.
sudo pmset -a disablesleep 1blocks sleep entirely, including lid close. Remember to set it back withsudo pmset -a disablesleep 0, or your battery will remind you. - Amphetamine (free, Mac App Store) is the GUI version: one click to keep the Mac awake for a set duration, with an option to allow the display to sleep while processes keep running.
The catch that gets everyone: closing the lid still sleeps most MacBooks unless the machine is plugged in AND connected to an external display, or you have forced it with pmset disablesleep. caffeinate alone does not override lid close. If your overnight plan is a closed MacBook in a backpack, the plan is the problem.
The overnight-run checklist
Before you start a long run and go to bed, take 2 minutes on this list:
- Detach the session. Agent running inside tmux (or via nohup/systemd), not bare in a terminal window.
- Kill sleep for the window.
caffeinate -ion Mac, disable suspend in power settings on Linux and Windows, or run on a machine that never sleeps. - Plug it in. Battery power plus a long agent run is a race you lose.
- Log to a file. Redirect output (
> run.log 2>&1) or rely on tmux scrollback so you can see what happened at 4am. - Cap the blast radius. Set spending limits with your model provider, and give the agent a scoped task with a clear done condition, not an open loop.
- Check for prompts. Many agents pause on permission questions. Pre-approve what you are comfortable with (for example a permissive mode inside a sandbox or VM) or the agent will sit waiting for input for 7 hours.
- Test the survival, not the task. Start the run, close the terminal, reattach. If it survived that, it will survive the night's disconnects.
The failure modes none of this fixes
tmux, nohup, caffeinate and friends solve the shell problem. They do not solve the machine problem. Things that still end your run:
- Crashes. If the agent process itself dies, tmux just shows you a dead pane in the morning. Only a supervisor (systemd with
Restart=always, or a managed platform) restarts it. - Reboots. OS updates on macOS and Windows can force a restart overnight. Everything not registered as a boot service is gone.
- Power and network. A power blip or your router's 2am firmware update kills the run on any home machine.
- The machine has another job. Your laptop eventually has to go in a bag. Every fix above is a workaround for the fact that a personal machine is not an always-on server.
This is the honest boundary. Keeping one machine awake for one night is a solved problem. Keeping an agent alive for weeks (through crashes, reboots, updates, and your own travel) is server operations, and every fix above only postpones that fact.
When a $10 always-on box beats all of it
The pattern behind every fix in this article is the same: move the agent's lifetime off your terminal, then off your laptop. The end state of that pattern is a machine whose only job is to run the agent.
You can build that yourself with a $5-10/month VPS plus tmux plus systemd plus your own patching and security. That route is legitimate and we wrote it up in detail for Claude Code and Codex. The full menu of places an agent can live, from home hardware to serverless, is in the AI agent hosting guide.
Or you can rent the end state directly. Hivra provisions a private VM per agent and runs the official CLI on it, unmodified: Claude Code (sign in with your own Anthropic account), Codex (your own ChatGPT login), Hermes, and Aeon all launch on the free tier. You get a browser view of the session (chat, terminal, files), so checking on the 4am state does not require SSH from your phone.
Honest plan math: the free tier is $0 for 1 agent, but free boxes sleep after 4 idle days and skip browser automation. True always-on is the Pro plan at $9.99/month for up to 3 agents, or Power at $19.99/month for 5. There is zero markup on AI usage because model billing stays on your own Anthropic or OpenAI account. Details on the pricing page.
If you enjoy running servers, run the server. If you just want the agent alive tomorrow morning, and every morning after, the $9.99 box is the version of this article that maintains itself.