I Stopped Developing on My Local Machine. The Remote Command Center Replaced It. / xShellz

I lost a three-hour AI coding run because my laptop went to sleep during a WiFi hiccup. The agent was halfway through refactoring a messy codebase, and when I reopened the lid, the SSH session was dead and the local terminal's buffer held nothing but a broken pipe.

It wasn't the agent's fault. It was my hardware. My machine had become the weakest link in a workflow that increasingly expects persistence. That morning, I decided my laptop would never be a development machine again.

The Problem with Laptop-First Development

Modern developer tooling assumes state. AI agents plan, generate, and iterate across dozens of files; they don't work in a single command invocation. Long compiles, dataset processing, and even a simple while read loop that pulls from an API all expect the machine to stay awake and the network to hold. Laptops break both assumptions.

Sleep, lid close, flaky coffee-shop WiFi, low battery, and OS updates create a world where your work lives on borrowed time. Screen multiplexers like tmux help, but if your terminal runs locally, you still lose the agent's PID and any in-memory context when the client disappears. The real fix is to move the developer's "home" off the local device entirely.

What a Remote Command Center Actually Looks Like

A remote command center is a persistent Linux box that runs your shell, your tools, and your long-lived processes, independent of whatever you use to connect. Your laptop, tablet, or even an old Chromebook becomes a thin client: it opens an SSH or Mosh session into that box, attaches to a tmux window, and picks up exactly where you left off.

Key ingredients:

A persistent host: a VPS, a home server, or a cloud dev environment that does not sleep.
A multiplexer: tmux or screen so you can detach and reattach from any client.
Network resilience: Mosh (mobile shell) to handle changing IPs and lag.
Optional but valuable: Tailscale or WireGuard for secure access without exposing ports, and an always-on IRC bouncer or chat bridge that stays connected when your laptop closes.

The shift is subtle but profound. Your laptop no longer carries your working tree, your agent's state, or your compile cache. It carries only a terminal emulator and a browser.

AI Agents Need Persistence (Not Just More RAM)

AI coding agents flip the old interactivity model. Where a compiler runs and exits, an agent often runs for many minutes or hours, planning, writing code, running tests, and iterating. Tools like Claude Code, Aider, or xShellz's borg are designed to run inside a terminal and own a session. If that session evaporates because the client disconnected, you lose not only the work in progress but also the conversation context that got the agent to its current state.

When you run an agent inside a persistent remote shell, you do this:

# Start a new detached session
tmux new -s refactor
# Launch the agent (example with borg)
borg run --task "refactor the auth module and run the test suite"
# Detach and go offline
Ctrl+B d

Hours later, from your phone or another laptop:

ssh my-shell
# Reattach
tmux attach -t refactor

You see the agent's output as if you never left. It doesn't matter that the client went to sleep, changed networks, or ran out of battery. The agent's process tree, including any background jobs it spawned, is still alive because the remote host is always on.

This also removes the temptation to "just let it run" by disabling sleep on a laptop and hoping the WiFi stays up. A $6/month VPS with 2 vCPUs can often handle more agent workloads than you'd expect, and it never gets closed by an airline seatmate.

How to Set Up Your Own

You don't need a special service. Spinning up a Debian or Ubuntu droplet on any cloud provider, installing your dotfiles, and running tmux gets you 80% of the way. A few things make the experience smoother:

Use mosh instead of vanilla SSH for high-latency or roaming connections.
Store your dotfiles and tools in a repository so you can re-provision quickly.
Keep your remote editor's dependencies server-side (neovim, emacs, vscode-server) so you never wait for local plugins to index.
Forward your SSH agent judiciously for Git access, or better, let the host hold its own keys.
Set ClientAliveInterval and TCPKeepAlive on the server to avoid zombie connections, but don't rely on them alone; a multiplexer is the real safety net.

I still keep a copy of my dotfiles locally. When I'm completely offline, I can write code and push later. But I treat that as an exception, not the primary mode. The default is connect, attach, work, detach.

The Thin Client Life

Moving to a remote-first workflow changed how I think about hardware. My daily driver is now a mid-range laptop with good battery life and a sharp screen, because all it does is render text and a browser. I don't care about RAM, disk speed, or CPU cores; those battles moved to the remote box, where I can resize resources without touching my physical machine.

It also makes device hopping seamless. I can start a task on my desktop, walk to a coffee shop, and reattach from an iPad with a keyboard. Nothing was transferred. No state was synced. The terminal was just a window into the same persistent session.

This pattern started years ago with IRC bouncers and screen sessions on shared hosts. It's funny that a generation of developers built tooling around the assumption of ephemeral local machines, only to rediscover the value of the always-on shell when AI agents and background pipelines demanded longevity.

If you already run a shell box for IRC or small services, try moving your development work there for a week. Use tmux. Launch your AI agent inside it. Detach and reconnect from different devices. You'll quickly find that the machine in front of you stops mattering. Its only job is to get you to the one that never sleeps.