My AI Agent Ran for 6 Hours, Then My Laptop Fell Asleep. I Fixed It Once and for All.

Last Tuesday, I kicked off a long-running refactor with my AI coding agent. It was supposed to scan 50,000 lines of legacy Python, apply a series of transformations, and produce a clean branch. Six hours in, I closed my laptop lid to head home. When I opened it again, the terminal was dead. The SSH connection had timed out while the machine slept, and the agent process was gone. No checkpoint, no partial result. Just a blank prompt.

That was the moment I realized my local machine is the single point of failure for any task that runs longer than a coffee break. The problem isn't the agent or the script. It's the environment you're running on.

The Fragility of Local Development

Developer laptops are terrible at staying awake. If you close the lid, walk away with a cup of coffee, or let the machine idle past a power‑management threshold, the operating system will suspend everything. All those running processes, SSH sessions, and tmux windows freeze. When the machine wakes up, connections are gone and background jobs are dead. Even a "stay awake" setting is often overruled by a forced OS update or a battery‑saving policy you forgot you configured.

Wi‑Fi is another silent killer. A five‑second network blip while you're working over SSH, and the session drops. Your local terminal doesn't reattach automatically, and any process that was attached to that TTY receives a SIGHUP. Tools like tmux or screen can detach from the terminal, but they still run on your local host. If the host itself goes to sleep, so does the tmux server.

Then come the forced reboots. macOS and Windows will restart your machine for updates, often without waiting for your consent. On Linux, a misconfigured unattended‑upgrades package can do the same. The result is identical: every shell, every agent task, every unsaved edit vanishes. You learn the hard way that your laptop is not a server. It's a client that shuts itself off at the worst possible moment.

The Real Fix: A Persistent Remote Shell

If you want a process to survive your laptop closing, you can't run it on your laptop. The solution is a headless workspace: a remote Linux shell on a machine that never sleeps, never drops its network because you left the coffee shop, and never reboots without your explicit command.

This isn't complicated. You SSH into a remote host, start a tmux session, and run your long‑lived command inside it. Your laptop becomes merely a thin client. When you disconnect for any reason (lid closed, Wi‑Fi gone, OS update), the tmux session stays alive on the remote server. Hours later you can reconnect from any machine, reattach to tmux, and find your agent still chugging along with all output intact.

Here's the basic setup in two minutes:

# SSH into a remote Linux host
ssh user@my-remote-shell

# Create a named tmux session so you can reattach later
tmux new -s work

# Inside tmux, run your agent or long task
borg run "refactor all legacy modules to use async/await"

Now detach from tmux with Ctrl+b d and close your laptop. The remote shell keeps running. When you're back, ssh in again and reattach with tmux attach -t work. Everything is exactly where you left it.

If you don't already have a remote Linux box, any cloud VPS works. I use xShellz for this because they provide a persistent shell that's already set up, with SSH access and a pre‑configured tmux environment. I spend zero time managing a VPS; I just open a terminal and run ssh.

Why This Matters for AI Agent Workflows

AI coding agents like borg (the one I run inside that remote tmux session) are not instant. A large‑scale code analysis can take an hour. A multi‑file refactor across a monorepo might need several. If the agent is running locally and your machine sleeps, you lose the entire session and have to start from scratch. Most agents don't checkpoint intermediate work, so a single hiccup costs you the whole run.

Moving the agent to a persistent remote shell turns it into a background worker. You can start a task before bed, close your laptop, and wake up to a finished branch. The agent doesn't care that your machine was offline; its host never was.

The same principle applies to any terminal‑heavy workflow: log monitoring, data crunching with jq on a live API stream, or a while true script that polls a CI pipeline. If it runs longer than the time you trust your laptop's uptime, it belongs on a remote shell.

Bonus: Always‑On IRC Bouncers

An always‑on Linux host is also the natural home for an IRC bouncer like ZNC. If you're still on IRC, you know the pain: your client disconnects when your laptop sleeps, and you miss messages. Run the bouncer on the remote shell, and it stays connected 24/7. Later, your local IRC client connects to the bouncer and catches up. It's the same mental model: separate the always‑on service from the ephemeral device you carry around. xShellz bundles a managed bouncer for exactly this, but even a minimal shell gives you the power to set one up yourself.

No More Lost Runs

Once you experience a terminal session that survives every sleep, every network blip, and every OS nag screen, you stop trusting your laptop as a runtime environment. You treat it as a window into a remote workspace that never goes to sleep. For me, that change eliminated the dread of opening my laptop after a commute and wondering if the agent had died again. It never does.