How to keep coding agents running after you close your laptop

You hand Claude Code a refactor that touches forty files. It starts working. You close your laptop to catch a train, open it twenty minutes later, and the run is gone — no output, no partial diff, no way to resume. The agent didn't crash. Your machine simply stopped existing as far as the process was concerned.

This is the single most common frustration with long agent runs, and it has four fixes with very different amounts of effort behind them.

Why the process dies

Closing a laptop lid triggers sleep, which suspends every running process. On macOS the kernel also aggressively reclaims resources from terminal sessions, and network sockets are torn down. A coding agent is a long-lived process holding an open HTTP connection to a model API, so it is hit from both directions at once: the process is frozen, and its connection to the API is dropped.

Even if the process survives sleep, the API connection will not. Most agent CLIs treat a dropped connection mid-request as a fatal error, because they can't know whether the tool call they were waiting on completed.

Three things have to be true for a run to survive:

1. The process must keep getting CPU time.
2. Its network connection must stay up.
3. Its terminal session must not be destroyed when the client disconnects.

Local fixes can give you one or two of these. Only moving the process off your laptop gives you all three.

Option 1: Stop the laptop from sleeping

The lowest-effort fix. On macOS, caffeinate prevents sleep for the lifetime of a command:

caffeinate -i claude

The -i flag prevents idle sleep. The agent now survives an idle timeout — but not a closed lid, unless the machine is plugged in and you've also disabled lid sleep, which requires pmset changes that affect your whole system.

This is worth doing for a run you expect to take fifteen minutes while you go get coffee. It is not a real answer for anything longer, and it means leaving your laptop open and awake.

Option 2: tmux, locally

Running the agent inside a tmux session detaches it from your terminal emulator, so quitting the terminal doesn't kill the agent:

tmux new -s agent
claude
# Ctrl-b then d to detach
tmux attach -t agent

This solves problem 3 from the list above and nothing else. Your terminal app can close, but if the laptop sleeps, the tmux server sleeps with it. People are frequently surprised by this, because tmux feels like it should be the answer. It's the right tool aimed at the wrong problem — tmux protects you from a dying client, not a dying host.

Option 3: tmux on a remote box you set up yourself

Now the pieces fit together. Rent a VPS, SSH in, start tmux, run the agent inside it. The machine never sleeps, the network never drops, and detaching from SSH leaves the session running. You can reconnect from a different device entirely.

The catch is everything you have to do before the first agent run:

• Provision the server and harden SSH.
• Install a current Node runtime, plus Python, plus whatever your project needs.
• Install and authenticate each agent CLI, which usually means completing an OAuth flow in a browser on a machine that has no browser.
• Get your repository onto the box, which means SSH keys or a token.
• Install and configure PostgreSQL if your app needs a database.
• Open ports, or set up a tunnel, so you can actually see a dev server.
• Configure TLS if you want to share a preview link.

This is a real afternoon of work, and it's an afternoon you repeat every time you rebuild the box. It's also a security surface you now own. Plenty of developers do exactly this and are happy with it. Plenty of others start, hit the OAuth step, and give up.

Option 4: A machine that arrives configured

The setup cost above is fixed work with a known answer, which makes it a good candidate to not do yourself. This is the gap ForgeVPS is built for: an always-on machine where the agents are already installed and authenticated, the editor and root terminal are in the browser, PostgreSQL is already running locally, and dev servers get a preview URL with HTTPS without you configuring anything.

The workflow becomes: start the agent, close the laptop, open the live URL from your phone to see what it built.

Which one to pick

If your runs are short and you're at a desk, caffeinate is fine and costs nothing. If you mainly want to close your terminal rather than your laptop, local tmux is enough.

If you regularly hand agents work that takes longer than your attention span, the process needs to live somewhere that isn't your laptop. Whether you build that machine yourself or use one that comes ready is a question of whether your afternoon is better spent on server configuration or on the thing you were actually building.