How to Keep an AI Agent Running After You Close Your Laptop

Your laptop lid is a kill switch

It is 11pm. Your agent is 40 minutes into refactoring a repo, or halfway through a batch of outreach emails, and you close the lid to go to bed. In the morning the terminal is gone, the run never finished, and whatever it half-wrote is in some unknown state. If you searched "how to keep ai agent running after closing laptop", that is the loop you want to break, and this post is the fix, not the autopsy.

The mechanics of why a closed lid takes your process down with it (sleep, suspend, a dropped SSH session, the SIGHUP that follows) get their own writeup. If you want the full explanation of the failure, read why it happens. Here we skip the theory and just make it stop, starting with a 5-minute patch you can do right now and ending with a setup that survives a reboot, a crash, and you being on a plane.

How to keep ai agent running after closing laptop, ranked from quick to bulletproof

There are really two families of fixes, and they are not equal. One keeps the process alive on the laptop you already have. The other admits the laptop was never the right home for a long-running process and moves the agent somewhere that stays on by design. The first is a stopgap. The second is the actual fix.

Here is the honest tradeoff before you pick:

Read that table top to bottom and the pattern is obvious: everything that keeps your agent tied to the laptop has a "no" in one of the reliability columns. If you only remember one thing, remember that the goal is to keep your AI agent running after you close your laptop without depending on the laptop being awake, plugged in, and on Wi-Fi. The bottom two rows get you there. The top two buy you a night, maybe.

Stopgap 1: nohup, tmux, and telling your laptop not to sleep

If you need something working in the next five minutes and the agent has to finish one run, start here. Just know these are patches, and I will show you where each one leaks.

A bare command dies when its parent shell or SSH connection goes away. nohup detaches it from that hangup signal and sends output to a file:

nohup python run_agent.py > agent.log 2>&1 &

nohup python run_agent.py > agent.log 2>&1 &

Better than nohup for anything interactive is a terminal multiplexer. tmux keeps a session alive on the host independent of your terminal, so you can detach, disconnect, and reattach later:

# Start a named session that outlives your terminal
tmux new -s agent

# ...launch your agent inside it, for example:
python run_agent.py

# Detach without stopping it: press Ctrl-b, then d.
# Reconnect later from any shell on the same machine:
tmux attach -t agent

# Start a named session that outlives your terminal
tmux new -s agent

# ...launch your agent inside it, for example:
python run_agent.py

# Detach without stopping it: press Ctrl-b, then d.
# Reconnect later from any shell on the same machine:
tmux attach -t agent

Both of those solve the "my SSH dropped" problem. Neither solves the real one, which is that a closing lid usually puts the whole machine to sleep, and a sleeping machine runs nothing. So the second half of the stopgap is telling the OS not to suspend.

# macOS: keep the machine awake for the duration of a command
caffeinate -s python run_agent.py

# Linux with systemd-logind: stop lid-close and idle from suspending
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

# macOS: keep the machine awake for the duration of a command
caffeinate -s python run_agent.py

# Linux with systemd-logind: stop lid-close and idle from suspending
sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Now be honest with yourself about what you just built. You have a laptop that will not sleep, is burning battery or needs to stay plugged in, cannot be moved without losing Wi-Fi, and loses everything the moment macOS installs an update and reboots at 3am. tmux does not survive a reboot. caffeinate does not survive a kernel panic. And "my laptop must never sleep or close" is a strange constraint to accept for something you wanted to be autonomous. These tricks are genuinely useful for finishing one job overnight. They are a bad foundation for an agent you expect to be running next week.

The real fix: move the agent off your laptop

The durable answer is boring and it works: put the agent on a computer whose entire job is to stay on. That is a small cloud server (a VPS) or a managed runtime. Your laptop goes back to being a laptop, and closing the lid means nothing to the agent because the agent is not there anymore.

Option A: a $5 VPS with a systemd service

A basic cloud VPS runs about $4-6/month for 1-2 GB of RAM, which is plenty for most single agents. Spin one up, get your agent code and dependencies onto it, then hand the process to systemd so the OS supervises it. This is the step that makes it real, because systemd will restart the agent if it crashes and bring it back up after a reboot.

The bootstrap before the service is short and you only do it once:

1. Create a dedicated non-root user (call it agent) so the process is not running as root.

2. Copy the code over with git clone or rsync, then build the virtualenv and install dependencies.

3. Put API keys and other secrets in a .env file owned by that user, readable only by it. Do not paste keys straight into the unit file, since anyone who can read the service can read them.

4. Lock the box down: a firewall that allows only SSH, key-based login, and automatic security updates. An always-on server that nobody watches is a target.

Once the code runs by hand, create a unit file at /etc/systemd/system/agent.service:

[Unit]
Description=Always-on AI agent
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=agent
WorkingDirectory=/home/agent/app
ExecStart=/home/agent/app/.venv/bin/python run_agent.py
Restart=always
RestartSec=5
EnvironmentFile=/home/agent/app/.env

[Install]
WantedBy=multi-user.target

[Unit]
Description=Always-on AI agent
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=agent
WorkingDirectory=/home/agent/app
ExecStart=/home/agent/app/.venv/bin/python run_agent.py
Restart=always
RestartSec=5
EnvironmentFile=/home/agent/app/.env

[Install]
WantedBy=multi-user.target

The line that earns its keep is Restart=always: if the agent exits for any reason, systemd waits five seconds and starts it again. Combined with WantedBy=multi-user.target, the service also comes back on its own after the box reboots. Enable and watch it:

sudo systemctl daemon-reload
sudo systemctl enable --now agent
sudo systemctl status agent
journalctl -u agent -f

sudo systemctl daemon-reload
sudo systemctl enable --now agent
sudo systemctl status agent
journalctl -u agent -f

That is the whole trick. journalctl -u agent -f tails the logs so you can confirm it is alive. Then prove it to yourself: run sudo reboot, wait a minute, SSH back in, and check systemctl status agent. It should already be running without you touching it. That single test is the difference between "I think it survives" and "I watched it come back." For the rest of the knobs (restart backoff, resource limits, restart-on-failure only), the systemd service documentation is the source of truth. This setup will happily keep an agent running for months, and it costs less than a coffee. The price you pay is ownership: you patch the OS, you rotate keys, you notice when the disk fills, you get paged when it wedges. For a lot of engineers that is a fine trade. For some it is exactly the babysitting they were trying to escape.

Option B: a managed always-on runtime

If you would rather not own a server at all, a managed runtime does the same job one level up. Instead of writing a unit file, you pick an agent and the service keeps it running and restarts it automatically if it crashes.

Sokko is one option here. You deploy one of four ready-made agent runtimes (OpenClaw, Hermes, Paperclip, OpenSRE) from the dashboard in a couple of clicks, bring your model keys or use Sokko credits, and it runs as an always-on service on infrastructure we manage. The agent survives you closing the laptop, and its files and memory are saved and survive restarts. That persistence is the part that separates it from a bare "process is running" fix: a crash or a redeploy does not wipe the state the agent built up. You get the always-on behavior of the VPS route without hand-rolling systemd, firewall rules, and reboots. It is one option, not the only one. A $5 VPS with the unit file above is completely legitimate, and some people prefer it precisely because they control the box. Pick based on whether you want to run infrastructure or just run the agent.

If your agent is Claude Code specifically, Sokko is not the host for it: Sokko runs its own agent runtimes, and Claude Code is not one of them. The move that works there is the VPS route above, and there is a dedicated walkthrough for that path in keep your Claude Code agent running without a Mac mini.

What "off your laptop" actually buys you

It is worth being precise about why moving hosts fixes the problem that tmux and caffeinate only paper over. A few things change the moment the agent lives somewhere always-on:

• Lid close is a non-event. The agent is not running on the machine whose lid you closed, so suspend, sleep, and hibernate stop being your problem entirely.

• Reboots heal instead of kill. With Restart=always or a managed runtime, a restart brings the agent back automatically instead of ending its life.

• Network drops stop mattering. Your home Wi-Fi flaking, or you walking into an elevator, no longer interrupts a run, because your laptop was only ever the remote control, not the engine.

• State can outlive the process. On a VPS you get this by keeping data on the server's disk and backing it up. On a managed runtime like Sokko the agent's files and memory are saved for you and outlive the process. Either way, "the run died" stops meaning "the work is gone."

That last point is the one people underestimate. Keeping the process alive is only half the job. Keeping what the process produced is the other half, and it is why "just leave the laptop open" was never really a solution even when it technically worked.

Which fix should you actually pick?

Match the fix to how long you need the agent up:

1. One overnight run, then done. tmux plus caffeinate or the masked sleep targets. Cheap, fast, disposable. Do not build a habit on it.

2. An agent you want up for weeks, and you are comfortable with a server. The VPS plus systemd route. Around $4-6/month, full control, some ops overhead.

3. An agent you want up indefinitely and you would rather not run infrastructure. A managed always-on runtime. Slightly more money, far less babysitting, state that persists by default.

The mistake is staying on rung one for something that belongs on rung two or three. If your agent matters enough that a dead run ruins your morning, it matters enough to live off your laptop.

Where to go next

• The deeper "always-on, no babysitting" version of this, including monitoring and restarts, lives in how to run an AI agent 24/7.

• Still fuzzy on the failure itself? The companion post explains why it happens in detail, from SIGHUP to suspend.

Do the five-minute tmux patch tonight if you have to. Then, this week, move the thing off your laptop for good. That is how you keep an AI agent running after you close your laptop for real, not just for one night, and finally stop treating the lid as an off switch.