← All posts

I cut my morning terminal ritual from 10 minutes to zero. The remote shell trick

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

Every morning, I used to open my laptop, launch my terminal, SSH into a few boxes, reattach tmux sessions, and restart the AI coding agent that was helping me with a long-running refactor. The ritual took 10 to 15 minutes, and I'd invariably lost the test suite results that had been running overnight (my laptop slept, killing the SSH connection). It was a slow, fragile way to work.

Then I moved my entire development brain to a remote Linux server that never sleeps. The change was trivial to set up, but it eliminated the daily tear-down and rebuild of my context. Today, I can close my laptop at any point, walk away, and resume exactly where I left off hours later, even from a different machine. The AI agent, borg, stays running in the background, continuously processing the project and keeping me in the loop.

Here's why shifting to a persistent, remote-first development environment matters, and how you can build one yourself.

The problem with ephemeral local terminals

Local development works until you have to stop. Long-running tasks (test suites, model training, data imports) get killed when your laptop sleeps or when you accidentally close the lid. If you use tmux or screen locally, you still lose the session when the machine reboots or loses power. Context is fragile. You spend time re-establishing mental state: which terminal was in which directory, which command was running, and what the AI agent had suggested.

Even with modern tools, the local machine is a single point of failure. I've lost hours of experimentation because I forgot to save a terminal buffer or because a kernel panic nuked my in-memory state. The fix is to move the persistence away from your laptop.

A persistent remote shell keeps your context alive

Instead of running everything locally, I SSH into a remote Linux box that stays up 24/7. Inside that box, I use tmux to manage multiple panes: one for editing, one for running servers, one for testing, and one for the AI agent. When I disconnect, I simply detach (Ctrl+b d). When I reconnect, I attach to the same session and everything is still there, exactly as I left it.

# From any machine
ssh user@my-dev-box -t tmux attach

No more reconnecting to multiple hosts, no more restarting background processes. Long-running tasks keep running while I'm away. I can start a build at night, close my laptop, and check the results in the morning. The state survives.

This shift alone saved me that 10-minute daily ritual. But the bigger win came when I added an AI coding agent into the always-on shell.

Adding an AI coding agent that never sleeps

Most AI coding tools are tightly coupled to an editor or a local process. When you close the editor, the agent's context disappears. That context is expensive to rebuild: the agent has to re-index the codebase, re-read your recent prompts, and re-understand the task you were in the middle of.

I run borg, an AI terminal coding agent, inside my remote tmux session. It watches the project directory, runs tests on file changes, and keeps a long-running conversation with me. Because it lives on the server, its state persists across my laptop disconnects. I can type a prompt, detach, and come back later to see the result. Borg can even run overnight tasks: refactoring a module, generating test stubs, or analyzing a log dump.

# In a tmux pane on the remote server
cd ~/project && borg run --watch .

That pane stays alive when I'm not connected. When I reattach, borg is already up to date with the latest file changes and has a list of suggestions waiting. It's like having a pair programmer who never logs off.

How I set it up

You don't need much. A cheap VPS with Linux, tmux, and your toolchain is enough. I use a small instance with 2 vCPUs and 4 GB of RAM, which handles most web development tasks comfortably. The key is to keep the session alive with a tmux config that starts a few panes automatically.

# ~/.tmux.conf
new-session -s dev -n main -d
send-keys 'cd ~/project' C-m
split-window -h
send-keys 'cd ~/project && borg run --watch .' C-m
split-window -v
send-keys 'cd ~/project && npm run dev' C-m
select-pane -t 0

Then I just ssh in and attach. If I want to work from a coffee shop, I use mosh for better latency, but the principle is the same.

Trade-offs and why it's worth it

There are downsides. Network latency is real, especially if you're used to local file I/O. I use tmux's copy mode and vim over SSH, which is fine for code, but heavy graphical editors won't work well. Security is another concern: you're exposing a server to the internet, so you need SSH keys, maybe a VPN, and good practices. However, for most of my daily work (CLI-heavy, terminal-centric), the trade-offs are minor compared to the productivity gain.

If you need a GUI, you can still use a remote shell as the backend and sync files with something like rsync or Unison, but that's a separate workflow.

The xShellz angle

I built this setup manually, but it's exactly what xShellz provides out of the box: a remote Linux shell with tmux, your favorite tools, and borg pre-installed. You SSH in, attach to a session, and you're immediately productive. No configuration, no wondering if borg is running. It's a managed version of the always-on developer environment I've been describing. You can certainly roll your own on any VPS, but if you want to skip the setup, it's worth a look.

Stop starting from scratch

Moving your terminal and AI agent to a server that never sleeps is a small change in infrastructure that pays off in uninterrupted focus. I no longer lose test results, AI context, or my train of thought just because I closed a laptop lid. The always-on remote brain is a straightforward way to keep your development momentum, and once you try it, you'll wonder why you ever tolerated the ephemeral local alternative.