← All posts

I lost an afternoon of AI work because my laptop went to sleep. Here's how I fixed it.

July 11, 2026 · 5 min read · The xShellz Team

I lost an afternoon of AI work because my laptop went to sleep. Here's how I fixed it.

Last month I kicked off a big refactor. I told my AI coding agent to rename a deeply nested library across 140 files, generate migration scripts, and run the test suite after each batch. The agent estimated 90 minutes. I grabbed coffee, walked to a meeting, and came back to a dark screen. My laptop had gone to sleep. The shell was gone. The refactor was dead. No partial state, no checkpoint. Just a cold terminal and a feeling I had paid in tokens for nothing.

I have had this happen with OS updates rebooting in the middle of the night, VPN drops breaking a long compile, and simply closing the lid when I moved between rooms. Every time, a local machine's power management or network flakiness turned a productive tool into a fragile toy. I finally fixed it by moving my heavy terminal work to a persistent remote Linux shell that never sleeps, never loses its network lease, and never reboots mid session. If you run AI coding agents, long CI jobs, or any process that cannot survive a disconnect, your local machine is a single point of failure you should remove.

Your laptop will betray you at the worst time

Modern laptops are designed to conserve power and apply updates, not to host persistent server processes. Close the lid and the kernel suspends. Walk away too long and the display sleep timer kills your ssh session. macOS can silently restart for an update even when you think you disabled it. Windows Update has its own ideas about rebooting. On Linux, a suspend after 30 minutes of inactivity might be the default. Add a flaky coffee shop Wi Fi connection and you have a recipe for a dead terminal right when your AI agent was halfway through a 50 file edit.

Even if the machine stays awake, a network hiccup will drop your session unless you run something like tmux or screen on the remote side. But many developers still start these agents directly in a local shell. The moment the connection breaks, the shell is gone and so is the agent process. There is no resume. You start over.

AI coding agents need a server, not a client

Most AI coding agents (including our own borg, Claude Code, and other terminal based assistants) live inside a shell. They can spend minutes or hours iterating over a codebase: reading files, proposing edits, running linters and tests, and applying changes across dozens of files. If the underlying shell dies, the agent has no way to recover its state. You are left with neither the modified code nor the intermediate reasoning. Re-running wastes API tokens and time.

The fix is to run the agent inside a terminal multiplexer like tmux on a remote machine that stays alive regardless of what your laptop does. You start a tmux session, fire off the agent, detach, and then close your laptop, move rooms, or lose Wi Fi. When you reconnect and attach to the same session, the agent is still chugging along, unaffected by your local machine's power state.

The headless workflow that saved my sanity

I now treat my laptop as a thin client, nothing more than a terminal emulator. All heavy work happens on a remote Linux box that sits in a data center. I keep a tmux session with multiple windows: one for an IRC bouncer, one for my AI agent, and one for long builds and database migrations. I can detach before lunch, go to a meeting, and later SSH in from my phone to check progress. The remote machine does not have a lid to close or a battery to drain.

This is not just about avoiding accidental sleep. It decouples your development environment from your physical hardware. I can wipe my laptop, upgrade its OS, or even switch devices entirely, and the real work keeps running untouched. The remote shell becomes your permanent, always on home for terminal work.

How to set up your own persistent shell (with or without us)

You can spin up a cheap VPS for a few dollars a month, install your tools, set up tmux, and ensure sshd keepalive settings are tuned for long sessions. But then you own the maintenance: OS patches, security updates, and the quiet 3 a.m. reboot that might still happen if you do not configure it carefully.

At xShellz we built persistent Linux shells precisely for this workflow. Every shell comes with tmux, ZSH, common dev tooling, and network settings optimized for sessions that last hours or days. We also include an always on IRC bouncer because many of us live in IRC channels while coding. It is what I personally use when I experiment with borg, and it is why I no longer lose an afternoon to a sleeping laptop. Whether you use our service or set up your own box, the concept is the same: a tmux session that stays alive independent of your local machine.

Real gains beyond not losing work

A persistent remote shell changes how you plan your day. I can kick off an AI refactor before bed and review the results in the morning without leaving my laptop awake and plugged in all night. I can share a read only tmux session with a colleague to debug something together. I can run resource intensive tasks on a beefy remote instance while my laptop stays cool and quiet. Battery anxiety around long running jobs disappears.

It also nudges you toward a reproducible, portable environment. Your dotfiles, tool versions, and shell configuration live on the remote machine, accessible from anywhere you can open an SSH client, including a tablet or phone.

Treat your laptop as a terminal, not a server

The mindset shift is simple. Your laptop is a window into your real workspace. The persistent remote shell is that workspace, and it never sleeps, never drops, and never reboots mid task. Since I made the move, I have not lost a single AI agent session. That alone has paid back the setup time many times over.