Home / Blog / Why your AI agent dies when you close the terminal (and every fix that works)
The agent did not crash. Your shell took it down.

Why your AI agent dies when you close the terminal (and every fix that works)

Claude Code, Codex, OpenClaw, Hermes: every terminal AI agent dies the same way when the terminal closes or the laptop sleeps. This is the full troubleshooting guide, from the 90 second tmux fix to systemd to the honest case for a $9.99 always-on box.

Hivra team15 July 202610 min read

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:

bash
# Start a named session and launch your agent inside it tmux new -s agent claude # or codex, or any CLI agent # Detach without killing anything: press Ctrl+b, then d # Reattach later, from any terminal or SSH connection tmux attach -t agent # List running sessions tmux ls

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:

bash
screen -S agent # start a named session # Detach: Ctrl+a, then d screen -r agent # reattach

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:

bash
nohup claude -p "run the test suite and fix failures" > run.log 2>&1 & # Watch progress tail -f run.log

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:

bash
# /etc/systemd/system/my-agent.service [Unit] Description=My AI agent After=network-online.target [Service] ExecStart=/usr/local/bin/my-agent Restart=always RestartSec=5 User=agent [Install] WantedBy=multi-user.target
bash
sudo systemctl daemon-reload sudo systemctl enable --now my-agent journalctl -u my-agent -f # logs

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:

bash
# Keep the Mac awake for as long as this command runs caffeinate -i claude # Or keep it awake while an already-running process lives (by PID) caffeinate -i -w 12345 # Or keep it awake for a fixed window, e.g. 8 hours caffeinate -i -t 28800

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 1 blocks sleep entirely, including lid close. Remember to set it back with sudo 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 -i on 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.

Common questions

Why does my AI agent stop when I close the terminal?

The agent is a child process of your shell. Closing the terminal sends SIGHUP to the whole session and the agent exits with it. Run the agent inside tmux or screen, or start it with nohup, and it survives the terminal closing.

Why does my AI agent keep stopping when my laptop sleeps?

Sleep suspends every process on the machine, so the agent makes no progress and its network connections usually die during the suspend. tmux does not help here. Keep the machine awake (caffeinate on Mac, power settings on Linux/Windows) or run the agent on an always-on machine like a VPS or a managed box.

Does tmux keep an AI agent running after I disconnect from SSH?

Yes. tmux runs the session inside a server process on the remote machine, so a dropped SSH connection changes nothing. Reattach with tmux attach -t <name> and the agent is exactly where you left it. It only fails if the remote machine itself sleeps, reboots, or loses power.

How do I run an AI agent overnight on a Mac?

Start the agent inside tmux, then keep the Mac awake with caffeinate -i (or Amphetamine), leave it plugged in, and leave the lid open unless you have disabled lid sleep with pmset. Log output to a file so you can review what happened. Note that closing the lid still sleeps most MacBooks even with caffeinate running.

What is the difference between nohup and tmux for AI agents?

nohup detaches a one-shot process from the terminal so it survives logout, but you cannot reattach or interact with it afterward. tmux keeps a full interactive session alive that you can detach from and reattach to. Use nohup for fire-and-forget headless runs, tmux when you might need to steer.

What keeps an AI agent running after a crash or a reboot?

None of the session tools do. tmux and nohup only protect against disconnects. For crash recovery you need a supervisor like a systemd service with Restart=always; for reboots the service must be enabled at boot. A managed platform like Hivra handles both on a per-agent VM.

Deploy in 5 minutes.

7-day money-back guarantee. BYO AI key. From $9.99/mo.

Start Now
Related reading
AI agent hosting in 2026: every real option compared (VPS, serverless, managed)How to keep Claude Code running 24/7 (even when your laptop closes)How to run Codex 24/7 in the cloudHow much does it cost to run an AI agent?Best VPS for Hermes Agent in 2026