I gave my AI coding agent a persistent Linux shell and it started shipping work while I slept

You have probably used an AI coding assistant inside VS Code. It completes lines, generates functions, maybe writes a docstring. You close your laptop and it is gone. That is a plugin.

The next step is an agent that lives in a persistent Linux shell, capable of running tests, linting, deploying, and even fixing issues while you are away. This is not about a fancier autocomplete. It is a different architecture entirely.

The short-lived plugin model

An IDE plugin runs inside the editor process. It can spawn commands, read files, and suggest code, but its lifespan is tied to the editor window. When you shut down VS Code, any background task it spawned dies. If you ask a plugin-based assistant to "run the full test suite and let me know what happens," you have to keep your laptop awake for the whole run. A one hour integration test? Not happening. Overnight regression checks? Forget it.

The plugin model works well for synchronous augmentation: completing a function, explaining a block of code, or generating a one-shot script. It falls apart the moment you need an agent to act asynchronously: monitor a directory, react to a webhook, or finish a long pipeline after you disconnect. Those are the kinds of tasks that turn a helper into a teammate.

What a persistent shell enables

A terminal-based agent running on a remote Linux box is a different animal. It has its own home directory, can install tools, fork child processes, and use tmux or screen to keep a session alive. It can read from stdin, write to log files, and manage its own filesystem without worrying about an IDE sandbox. Most importantly, its process tree survives your SSH session. You can disconnect and the agent keeps working.

This changes what you can ask. Instead of "generate a script," you can say "watch this repository, run the full CI pipeline on every push to dev, and create a Slack alert if coverage drops below 80%." The agent can spawn a long-running test runner, tail logs, and decide when to notify you. It behaves like a service, not a keybinding.

Because the agent owns a real Linux environment, it can use the same tools you use: git, make, npx, pytest, curl, jq. No need to rebuild workflows inside a plugin DSL. It just executes commands, parses output, and acts.

How I put my agent to work overnight

Here is a concrete workflow I use with Borg, the AI terminal agent on my xShellz remote shell. Before signing off for the evening, I open an SSH session and type a natural language task:

borg run the full test suite with coverage. If it passes, deploy to staging and post the URL in Slack. If it fails, look at the output, propose a fix, apply it, and open a pull request with the change.

Borg spawns the test runner, monitors its exit code, and branches on the result. I close the terminal and go to bed. My local machine is off, but the remote shell is still running, Borg is still running, and the task proceeds. In the morning I have either a staging deployment notification or a pull request with an attempted fix. The agent worked while I slept.

This is impossible with a plugin bound to an editor process. The plugin would die when the laptop closed. Even if it survived a sleep cycle, it could not orchestrate a multi-step pipeline with retries and conditional logic across hours because the OS would eventually suspend it.

The missing piece: an always-on Linux host

Persistent autonomy requires a Linux environment that does not go away. A laptop is not that. A VM you spin up ad hoc and tear down after a session is not that either, because any background job you left behind is gone.

You need a resident shell. That means a host you can SSH into at any time, with a filesystem that survives restarts, and preferably a terminal multiplexer so you can reattach to the agent's session. xShellz provides exactly that: an always-on remote Linux shell where you can run Borg (or any other terminal-based agent) and leave it working. You can also build your own by keeping a small VPS with tmux and your agent of choice, but the key is persistence.

The agent should have a stable home directory and enough resources to run typical dev workloads. It does not need to be powerful; a modest instance works for the kind of background tasks most teams want: tests, linting, formatters, simple deployment checks, and scheduled health checks.

Start thinking of your agent as a resident service

When you treat an AI assistant as a per-session tool, you limit it to the time you spend in front of your keyboard. A plugin can only react while you are present. An agent with a persistent shell becomes a background service that can work when you are away.

This shift changes how you use it. You start giving it longer-running tasks, trusting it to handle the plumbing, and checking results later. It also makes the agent a better collaborator for your team: anyone can SSH into the shell and ask the agent to do something, or inspect its logs.

The underlying idea is simple. Your code does not live only on your machine, and neither should the agent that works on it. Give it a home with a resident shell, and you will find yourself delegating real work, not just asking for completions.