← All posts

Your AI Coding Agent Dies When You Close the Lid. It Doesn't Have To.

July 18, 2026 · 4 min read · The xShellz Team

Most developers experience AI coding tools as editor plugins. You highlight some code, ask for a change, get a suggestion. It works, until you shut your laptop. That's fine for quick completions, but it misses the deeper promise: an agent that can grind through a massive refactor while you sleep. The key isn't a better plugin; it's a persistent remote shell that never sleeps.

The Plugin Ceiling

An IDE-bound assistant lives and dies with your editor process. Close VSCode or your terminal, and the agent's memory evaporates. Long-running tasks like "rewrite this 3,000-line module to use the new API and benchmark the result" become impossible. You either babysit your machine or break the work into tiny, sequential prompts you feed manually the next morning. The plugin model is inherently tethered to your hardware's uptime.

I hit this wall when I asked an agent to upgrade a Go service from a legacy auth framework. The task involved scanning dozens of files, generating migration scripts, running the test suite, and iterating on failures. My laptop couldn't stay awake through a six-hour build-and-fix loop. I needed a home for the agent that wouldn't disappear when I did.

Decoupling with a Persistent Shell

The solution is dead simple: run the agent on a remote Linux host, inside a terminal multiplexer like tmux or screen. The agent thinks it's just a long-running CLI process, but it's insulated from your local power management and network hiccups. You connect via SSH, attach to the session, see the progress, and detach. The agent keeps going.

This decoupling flips the model. Your laptop becomes a thin client. The agent's world, its file system, environment variables, running processes, lives on a server that stays up. You can start a coding session in the afternoon, disconnect, and pick up the results in the morning. If a task runs for seven hours, it runs for seven hours, not until your battery dies.

Real World "Always-On" Agent Tasks

Once you free an agent from the interactive session, you start assigning work that used to be manual or impossible:

  • Overnight refactors: "Adopt the new logging interface across all 120 service files. Run the full unit suite after each file and stop if something breaks."
  • Long-running code generation: Have the agent produce draft implementations for a new microservice, complete with Dockerfile and integration tests, while you're at dinner.
  • Regression hunting: "Run this flaky test in a loop for 10,000 iterations; capture the output and only alert me if it fails."
  • Dependency updates: Let the agent bump dozens of packages, resolve conflicts, run CI locally, and leave you a clean branch to review.

These aren't hypothetical. On a $6/month VPS running Ubuntu, I have an agent (the xShellz "borg" CLI, in my case) that churns through tasks in a tmux window. I drop a markdown spec into a directory, the agent picks it up, and it works. When I come back, I review the diff and the test log. No more idle waiting.

Setting Up Your Own Persistent Agent

You don't need exotic infrastructure. A modest Linux box with a couple of cores and 2 GB of RAM will handle a terminal-based coding agent fine. The recipe:

  1. Provision a remote host. A cheap VPS from any provider or a spare machine in your homelab works. Install your favorite distro.
  2. Install tmux and your agent. For a CLI-native tool like borg, it's usually a single binary. Clone your project repos.
  3. Start a tmux session, launch the agent with your task file, and detach (Ctrl-b d).
  4. SSH in whenever you want to check progress. You can reattach from anywhere, your desktop, a tablet over Mosh, even a phone if you're in a pinch.

Some services (xShellz is one) offer managed remote shells that come with borg pre-installed and hardware that stays on. If you'd rather skip the sysadmin bits, that's an option, but the core idea doesn't require anything you can't spin up yourself in ten minutes.

When Your Laptop Is Just a Thin Client

Treating your agent as a persistent process changes the way you think about coding tasks. Instead of asking "What can I do in the next 30 minutes?" you ask "What should be done by tomorrow morning?" The agent becomes a teammate that works while you don't. You're no longer the bottleneck between idea and result.

This doesn't replace interactive pair programming, and I still use editor plugins for small, real-time changes. But the heavy lifting, the kind that really benefits from a large language model's ability to hold context over thousands of lines, belongs on a machine that never goes to sleep.

Next time you find yourself keeping your laptop open just so an AI task can finish, ask yourself if you're using the right kind of assistant. A plugin is a tool that waits for your next keystroke. A persistent shell agent is a worker that keeps going long after you've walked away.