I stopped losing hours to dropped connections when I put my AI agent in tmux. Here's how.

I used to run AI terminal agents in a local terminal window. Every time my Wi-Fi hiccupped or my laptop went to sleep, the agent would die mid-task. Then I moved the agent into a tmux session on a remote shell. I haven't lost work to a dropped connection since. Here's why combining a terminal AI agent with a multiplexer changes the entire development loop.

The problem with local AI agents

Terminal-based AI coding agents, like Borg, Claude Code, and others, run as foreground processes. They accept natural language instructions and operate on your codebase right from the shell. The catch: if your connection breaks or you close the terminal, the agent dies. On your local machine, closing the lid might put the agent to sleep, but often the process is killed. On a remote server, a network blip ends it. Even if you use nohup or disown, you lose the interactive conversation history and the ability to monitor progress. This isn't just about convenience; it's about wasted time and lost context.

Enter the terminal multiplexer

A terminal multiplexer, like tmux or GNU screen, creates persistent sessions that stay alive even when you disconnect. You can detach from a session and reattach later, picking up exactly where you left off. The processes inside the session keep running, including their entire state: environment variables, background jobs, scrollback, and window layouts. This has been a sysadmin sanity-saver for decades. Now imagine that instead of a regular shell, you have an AI coding agent running inside that multiplexer. It's still there when you come back, with all its context: the git state, the conversation history, the half-finished refactor that the agent was working on. You haven't lost a single line of progress.

Putting it together: a stateful AI development environment

Here's the setup that turned my sporadic AI tasks into a reliable part of my workflow. I SSH into a remote Linux box (I use xShellz, which provides always-on shell access and includes Borg, but any VPS works). I start a tmux session specifically for my AI agent:

tmux new -s ai

Inside that session, I launch Borg (or whatever CLI agent I'm using). Then I give it a task, say: "Refactor the payment module to use the new pricing API across all services." The agent starts reading files, making changes, and occasionally asking for confirmation. At any point, I can detach with Ctrl-b d and close my local terminal. The session keeps running on the remote server.

When I'm ready to check in, I reconnect from any machine:

ssh user@host
tmux attach -t ai

I'm right back in the agent's conversation. I see the output it produced while I was away, I can review diffs, and I can give it new instructions. If my laptop battery dies mid-detach, no problem. The server never skipped a beat.

This isn't just disaster recovery. It means you can kick off a long analysis or a multi-file refactor, detach, and go to lunch. Return to a completed task with a full audit trail. You can even start a task from your phone via an SSH client and pick it up later on your desktop.

Why remote over local

You can run tmux locally, but if your local machine shuts down, the session dies. A remote shell, whether it's a $5 cloud instance or a dedicated hosting service, is always on. A service like xShellz takes this further: it's a remote Linux environment with tmux pre-installed, a persistent filesystem, and optionally the Borg AI agent right in the path. You don't have to manage the server; it's just there, like a shell that never closes. But you can achieve the same with a cheap VPS if you're willing to maintain it. The key is to offload the persistent state to a machine that doesn't travel in your backpack.

The terminal-first workflow

This approach fits naturally if you already live in the terminal. Instead of opening an IDE, you open a multiplexer window with your editor, another with a build watch, and a third with your AI agent. The agent becomes another tool in the belt, not a separate application you fire up and tear down. By keeping the agent inside a multiplexer session, you treat it like a long-running service: always available, stateful, and resilient. That's the terminal-first mindset: every tool is reachable with a few keystrokes, and nothing dies because you switched context.

xShellz was built with this philosophy. A remote shell that stays online, IRC bouncers that never miss a message, and a terminal AI that's ready whenever you attach. Borg runs natively there, so you can start a session, ask it to generate tests for a legacy codebase, detach, and come back hours later to find everything done. No IDE required.

Practical considerations

A few things to keep in mind. Tmux sessions consume a bit of memory, but a simple shell with an AI agent rarely exceeds a couple hundred megabytes. If you run many concurrent sessions, just give your remote host adequate RAM. Security: the AI agent has the same file access as your user; keep your SSH keys safe and use key-based authentication. If you're on a shared remote service, ensure you trust the provider. xShellz isolates shells at the user level and doesn't snoop, but that's true of any reputable host.

One neat trick: you can split the tmux window panes so you have the agent on one side and a code editor on the other, all in one persistent session. You can also share the tmux session with a colleague for live pair programming with the AI. That's beyond the scope of this post, but the combination of multiplexer and AI opens up those possibilities.

Start your next AI task in tmux

Next time you're about to run a terminal AI agent that might take more than a few minutes, put it in tmux. It's a one-command change that makes the difference between a fragile prompt and a resilient development partner. And if you're tired of managing servers, consider a remote shell service that bundles multiplexer and AI. Either way, your terminal just got a lot harder to kill.