Your AI Coding Agent Dies When You Shut Your Laptop. Here's How to Fix That. / xShellz

Most AI coding tools today live inside your IDE. They offer inline completions, chat panels, and the ability to edit files. They share a fatal design limitation: they die the moment you shut your laptop. The process is tied to your local editor session, so closing the lid means your agent stops whatever it was doing. If it was halfway through a multi-file refactor or waiting for a slow test suite to finish, you will have to start over the next morning.

That is not how an autonomous coding agent should work. A truly useful agent needs a persistent home, somewhere it can run background jobs, monitor long processes, and pick up work without you holding the session open. That home is a remote shell.

The local IDE trap

Plugins like Copilot, Cursor, and the new crop of AI editor assistants run inside the electron/chromium runtime of your editor. They are tightly integrated with your local file system and project state. When the editor closes, the agent process is killed. Even if you use a terminal inside the IDE, the underlying shell is usually attached to the editor process tree. No editor, no tty.

You can hack around this by leaving the editor open overnight. That burns battery, risks a crash, and ties your machine to a task. Worse, your development laptop might need a restart for an update, or you might take it on a train without network connectivity. The agent can not survive those interruptions. It can not run background test loops, long fuzz campaigns, or multi-hour model fine-tuning jobs in that environment, not reliably.

What a remote shell agent looks like

A terminal-based agent inside an always-on remote shell avoids all this. You SSH into a machine that never sleeps, launch the agent inside a tmux or screen session, and detach. The agent keeps working. You can shut your laptop, commute home, and later reconnect to find it has finished the task and left the terminal output ready for review.

For example, instead of asking your agent to "refactor the auth module" and watching it happen live in your IDE, you can type:

ssh mybox
borg task "refactor auth module to use Pydantic models, write tests, run the full suite, and leave a summary in /tmp/result.txt"

Then you detach. Hours later you can read the summary and inspect the diff, all while your laptop was asleep in your bag.

This is not just about convenience. It changes the kinds of work you can assign. A local IDE agent is a sprint partner that can only pair when you are both present. A remote shell agent is a background worker that can churn through work you would never babysit.

Long-running tasks are where persistence pays off

The real advantage shows in these scenarios:

Full test suite runs after a refactor. A large Django project can take 20 minutes to run all tests. An IDE agent that crashes after 15 minutes means you wasted time and context.
Background mutation testing or fuzzing. You can ask the agent to run a fuzzer against a library for 6 hours and email you the crash dump. That is impossible with a laptop that hibernates.
Automated PR review loops. An agent watching a repository, checking new pull requests, and running static analysis in a loop can be invaluable. It needs to stay running.
Long code migrations. Updating hundreds of files from JavaScript to TypeScript or switching a logging library is a batch job, not an interactive editing session. An agent that can execute the migration, fix import paths, and run linting while you sleep cuts days off the work.

Without a persistent environment, you have to break these tasks into small chunks that fit between lid-close events, or you do them manually. With an always-on shell, the agent does the slog.

Setting up an always-on agent with tmux and SSH

You do not need special infrastructure. A cheap VPS, a Raspberry Pi in the basement, or a managed shell service like xShellz all work. The pattern is the same:

Connect via SSH to a remote host that stays on.
Start a tmux session: tmux new -s agent.
Inside that session, launch your terminal agent (borg, an open-source agent, or even a long-running shell script).
Detach with Ctrl-b d and close your laptop.
Later, reattach: tmux attach -t agent.

The agent process lives in tmux's server process, which keeps running until the host shuts down. You can even script the agent to start automatically at boot with a systemd service, so it recovers if the host reboots.

Where xShellz fits (and where it does not)

xShellz is a remote shell hosting service that also ships with borg, an AI terminal coding agent. The shells are always on, and borg is designed to run in that persistent environment. Because the shell lives in a data center, you can start a long-running refactor, disconnect, and come back hours later to a completed task and a log of what changed. borg can also act as an IRC bouncer or a terminal-based assistant while you are away.

That said, you do not need xShellz to get the persistent agent pattern. Any remote machine with an SSH daemon and tmux will do. The key insight is that the agent process must outlive your local editor session. Plugins can not provide that; remote shells can.

If you already host your code on a server or use CI runners, try running your agent there. If you have not yet given a terminal agent a permanent home, the next time you close your laptop mid-task and lose an hour of work, consider moving that agent to a machine that does not sleep.