← All posts

Your laptop is the worst place to run a coding agent

July 13, 2026 · 3 min read · The xShellz Team

Your laptop is the worst place to run a coding agent

I left an AI coding agent running a multi-file refactor on my laptop and went to bed. When I woke up, the laptop had installed a security update overnight, rebooted, and sat patiently at the login screen. The agent was gone, its session vaporized, and my project was exactly where I'd left it. I had to redo the whole thing. That's when I realized my local machine was the single point of failure for any agentic workflow.

The local development trap

We've trained ourselves to treat laptops as universal development machines. They're fast, familiar, and they hold all our tools. But they were never designed for the long-running, stateful processes that AI coding agents need. Sleep modes suspend processes the moment you close the lid. A drained battery kills everything mid-task. Wi-Fi hiccups can sever an SSH session. System updates, especially on macOS and Windows, love to reboot without asking. Even a local terminal multiplexer like tmux can't protect you from a hardware restart or a forced sleep cycle. When an agent's context lives only in memory on a machine that can vanish at any moment, you're gambling every multi-hour task.

The session dies with your Wi-Fi

Most coding agents (Claude Code, borg, Aider, and similar tools) run as foreground processes inside a terminal. When the terminal disappears, the process receives SIGHUP and exits. Yes, you can wrap it in tmux or screen. That keeps the session alive if your SSH connection drops. But it doesn't protect you from a laptop that runs out of battery or decides to reboot for an update at 3 AM. The session, with all its in-progress reasoning and partial file modifications, is lost. You wake up to a blank terminal and a git status that hasn't moved.

Remote shells: always on, always reachable

The fix is simple but often overlooked: move the agent off your laptop and onto a machine that never sleeps. A cheap VPS or a dedicated Linux shell host changes everything. You SSH in, create a tmux session, launch the agent, detach, and close your laptop. The agent continues its work regardless of what happens to your local hardware.

ssh [email protected]
cd ~/project
tmux new -s agent
borg run "write integration tests for the payment module"
# Press Ctrl+b then d to detach

Eight hours later, you reconnect from any device: tmux attach -t agent. The output is waiting, the file tree is modified, and your local machine isn't even relevant. No battery anxiety, no surprise reboots, no corrupted context. The terminal feels local, but the reliability is that of a server.

This pattern isn't limited to borg. Any agent that runs in a terminal benefits from a persistent remote host. The terminal is a location-agnostic interface; it doesn't care where the process actually lives.

The xShellz example

At xShellz, we built our infrastructure around exactly this idea. We provide persistent Linux shells with no idle timeouts and no forced reboots. Borg, our AI coding agent, comes preinstalled so you can spin up a session and start a long-running task in seconds. For a few dollars a month, you offload the reliability problem and turn your laptop into a thin client. But the principle doesn't require xShellz; any always-on Linux host will do. The key is to stop using the device most likely to go to sleep as the runtime for processes that can't afford an interruption.

Stop treating your laptop like a server

The terminal's greatest strength is that it abstracts away the underlying hardware. A process running on a remote box is indistinguishable from a local one, until the local box dies. The mental shift is to treat your laptop as an interface, not as the compute environment for long-running agent tasks. Your laptop moves, sleeps, loses power, and updates itself. A persistent shell stays up. Once you make that change, you stop losing nights of work to macOS updates and start waking up to completed refactors, just like you expected all along.

That's the always-on developer mindset, and it's the only way to let agentic coding actually finish the job.