Why Your AI Agent Dies When You Close Your Laptop

When the lid clicks shut, your agent goes dark

You kicked off a long agent run before lunch. It was churning through a backlog, calling APIs, writing files to disk. You closed the laptop, walked to a meeting, came back an hour later, and it had gone nowhere. Half a task done. Frozen. If you have ever typed some version of "why does my ai agent stop when i close my laptop" into a search bar at that exact moment, this is the article that answers it.

Not the quick fix (that lives in a sibling post), but the actual mechanisms. There are five of them, they are separate, and closing the lid can trip three at once. Once you can name each one, the "how do I keep it running" part gets a lot less mysterious.

Why does my AI agent stop when I close my laptop?

Short version: your agent is fine. Its home is the problem. A laptop is a personal device that powers down, hangs up its terminals, changes networks, and has nobody watching the process. Ask it to behave like a server and it fails in five specific ways:

• Closing the lid puts the machine to sleep, so the CPU stops running your code.

• Closing the terminal (or dropping an SSH session) sends SIGHUP and kills the job.

• A local dev server is bound to your machine and its private network, so nothing outside can reach it.

• Your home IP and Wi-Fi keep changing as the laptop moves.

• Nothing restarts the process when it crashes.

Here is each one, concretely.

Cause 1: Closing the lid triggers sleep, and the CPU stops running your code

On almost every laptop, the default lid action is suspend. macOS, Windows, and most Linux desktops read a closed lid as "the human is done," so the OS drops into a low-power state. RAM stays refreshed so your session survives, but the CPU stops scheduling processes. Your agent is still sitting in memory. It just gets zero clock cycles.

That distinction matters. Your agent did not crash and it did not exit. It froze. Every timer, every polling loop, every open HTTP connection to a model API is paused mid-flight. A call that was streaming tokens when you shut the lid will usually have its socket time out and drop during the suspend, so even after you reopen the laptop the request is already broken. The agent wakes into a world where the thing it was waiting on is gone.

You can fight this. On macOS, caffeinate holds a process awake; on Linux you can change the logind HandleLidSwitch setting so the lid does nothing. Both are band-aids. You are keeping a hot laptop with its fans spinning inside a closed bag, which is not a runtime so much as a laptop slowly cooking itself. It also does nothing about the other four causes.

Cause 2: Closing the terminal sends SIGHUP and kills the job

Say you dodge sleep entirely. You keep the lid open, or you SSH into the machine and run the agent there. There is a second, unrelated killer: the controlling terminal.

When you start an agent with python agent.py in a terminal, that process is attached to the terminal as its controlling terminal, sitting in the foreground process group. Close the terminal window, quit the terminal app, or let the SSH connection drop, and the kernel sends SIGHUP (the "hangup" signal) to that process group. The default action for SIGHUP is to terminate. So the agent dies the instant the terminal goes away, with no traceback and no cleanup.

# Foreground: dies the moment the terminal closes (SIGHUP)
python agent.py

# Detached from the terminal: survives the hangup...
nohup python agent.py > agent.log 2>&1 &

# ...but close the lid and the whole machine suspends anyway (see Cause 1).

# Foreground: dies the moment the terminal closes (SIGHUP)
python agent.py

# Detached from the terminal: survives the hangup...
nohup python agent.py > agent.log 2>&1 &

# ...but close the lid and the whole machine suspends anyway (see Cause 1).

nohup, disown, or a multiplexer like tmux or screen detach the process from the controlling terminal so a hangup no longer reaches it. Those genuinely solve the terminal problem. They do nothing about Cause 1: a detached process still freezes the moment the machine suspends. This is the trap that catches most people. They run nohup, feel safe, close the lid, and the agent stops anyway.

Cause 3: Your dev server is bound to your laptop and its network

Plenty of agents are not a bare script. They are a small web service: a FastAPI or Express app exposing a /webhook endpoint, or a dev server you started with npm run dev or uvicorn --host 127.0.0.1. That server is bound to an address on your machine, usually loopback (127.0.0.1) or a private LAN IP handed out by your router.

Two things follow. First, the server only exists while the machine is awake and on that network, so it inherits every problem above. Second, nothing on the public internet can reach 127.0.0.1 on your laptop. If a Stripe webhook, a Slack event, or a GitHub callback needs to hit your agent, it cannot, because your address is private and lives behind NAT. People paper over this with a tunnel like ngrok or cloudflared. That is fine for a demo, but the tunnel process runs on the same laptop, so it drops the second you sleep the machine or switch networks.

Cause 4: Your home IP and Wi-Fi keep changing

Laptops move. That is the entire point of them. Over one afternoon your machine might hop from home Wi-Fi, to a cafe network, to a phone hotspot. Each hop changes your local IP address (a fresh DHCP lease), and your public IP changes too whenever your ISP rotates your home address, which residential ISPs do on their own schedule.

For an interactive app you never notice. For an agent that is meant to be reachable, or that holds long-lived connections, every address change is a small outage. Inbound webhook URLs point at an address that no longer exists. Persistent WebSocket or SSE connections to a model provider get reset on the network switch and have to reconnect, and if your code did not plan for a mid-run reconnect, the whole thing just stalls. A background agent needs a stable place to live, and a laptop is the least stable network location you own.

Cause 5: Nothing restarts the process when it crashes

Even on a machine that never slept and never moved networks, agents crash. They hit an unhandled exception, an out-of-memory kill when the context balloons, a provider rate limit that raises instead of backing off. On a real server you expect a supervisor to catch that. systemd with Restart=always, or a process manager like pm2 or supervisord, notices the exit and starts the process again within seconds.

A terminal has none of that. When your foreground python agent.py throws and exits, it stays exited. The agent is down until you happen to glance at the window, read the traceback, and run it again by hand. For something you wanted running 24-7, "until a human notices" is not an uptime strategy. This is exactly the gap that systemd's Restart= directive exists to close, and it is a big reason a laptop terminal is the wrong home for a long-lived process.

Which failure actually hit you, and when

Five separate mechanisms, and one closed lid can trigger three of them together. Here is how to tell them apart:

Notice the pattern: none of these are bugs in your agent. They are all properties of where the agent runs. So the real answer to why does my AI agent stop when I close my laptop is simpler than it looks. The laptop was never a server, and you asked it to act like one.

The real fix: run the agent somewhere that never sleeps

That pattern points straight at the fix. Every failure mode above comes from the agent sharing a fate with your laptop: its power state, its terminal session, its network, its lack of supervision. Break that coupling and they vanish together.

In practice that means putting the agent on a host that stays powered, sits on a stable network, and is watched by a supervisor that restarts it. You have a few honest options, and the tradeoffs get their own treatment in how to keep it running after you close your laptop and in the broader guide to running an agent 24-7:

1. Rent a small VPS (a $4-6/month box) and run the agent under systemd with Restart=always. Cheap, but you own the patching, the reboots, and the babysitting.

2. Use a container platform or managed runtime so the process is supervised and the storage persists, without you administering a server.

3. Keep a dedicated machine at home. Some people repurpose a Mac mini for this, which swaps the cloud bill for hardware you maintain. The Mac mini alternative covers why that is often more hassle than it is worth.

Here is the one place we will name our own product. Moving the agent off your laptop onto an always-on host with persistent storage (for example Sokko) removes all five failure modes at once. Sokko is a managed, always-on home for AI agents: you pick one of its runtimes (OpenClaw, Hermes, Paperclip, or OpenSRE) from the dashboard in a couple of clicks, bring your own model keys or use Sokko credits, and it runs around the clock with everything it saves surviving restarts. If Claude Code specifically is what you want running 24-7, the Mac mini post linked above covers that case. No lid to close, no SIGHUP, no shifting home IP, no manual restart. Whichever route you take, VPS, home box, or managed host, the principle is identical: the agent should not live on the machine you carry around.

Where to go next

You came here asking why does my ai agent stop when i close my laptop, and now you have the whole answer: it is where the agent lives, not the agent itself. Fixing where it lives is mechanical once you accept that a background agent needs its own home.

Start with how to keep it running after closing your laptop for the step-by-step, then read how to run an AI agent 24-7 once you want it dependable for the long haul.