Contents
TMUX is one of those tools that sounds intimidating until you understand what it does. Once you get it, you wonder how you worked without it.
If you’re developing on a remote server over SSH — and if you haven’t read my post on why that’s worth doing, start there — TMUX is the piece that makes the whole setup resilient.
The Problem It Solves
When you SSH into a server and start running things, everything you’ve done lives inside that SSH session. The moment that connection drops — bad Wi-Fi, your laptop goes to sleep, the coffee shop kicks you off the network — the session dies. Anything running inside it stops. You come back and you’re starting over.
TMUX breaks that link.
It runs as a server process on your remote machine. Your SSH connection attaches to that server, but it doesn’t own it. If the connection drops, the TMUX server keeps running. Your processes keep running. When you reconnect, you reattach to the existing session and pick up exactly where you left off.
This is not a small thing. If you’ve ever lost a twenty-minute Claude Code run to a dropped connection, you understand the value immediately.
Why It Works
TMUX operates as a persistent daemon on the server. When you create a session (tmux new -s myproject), you’re not creating a terminal tied to your SSH pipe — you’re creating a managed process under the TMUX server. Your SSH window is just a view into that process, like a window on a running application.
Disconnect the window, the application keeps running. Open a new window and reattach, you’re looking at the same state. The separation of “session” from “connection” is the core insight, and it’s powerful.
The Four Commands You Need
You don’t need to memorize a reference card. These four commands cover the vast majority of real use:
Start a new named session:
tmux new -s projectname
Give it a meaningful name — the project you’re working on, the task you’re doing, whatever helps you remember what’s in it.
Reattach to an existing session:
tmux attach -t projectname
This is what you run when you reconnect after a drop, or when you want to get back to a session you left running.
List all running sessions:
tmux ls
Shows you every session currently running on the server. Useful when you’ve got multiple projects on the go.
Detach from a session without killing it:
Ctrl+B, then D
This is how you leave a session running on the server while you step away. The session stays alive; you’re just not attached to it.
Those four things will carry you through almost everything. They become automatic fast because you use them constantly.
Splitting the Screen
TMUX lets you split your terminal into multiple panes — no mouse required, no second SSH connection, no extra windows to manage.
Split horizontally (one pane on top, one below):
Ctrl+B, then "
Split vertically (one pane left, one right):
Ctrl+B, then %
Move between panes:
Ctrl+B, then arrow key
A common setup: code in one pane, logs or test output in another, a third for running one-off commands. You can see everything at once without switching context. Once you’ve worked this way for a few days, a single pane starts to feel cramped.
Naming Windows Inside a Session
Within a session you can have multiple named windows (think of them as tabs):
New window:
Ctrl+B, then C
Rename current window:
Ctrl+B, then ,
Switch to next/previous window:
Ctrl+B, then N / P
Visual session/window picker:
Ctrl+B, then W
This one is underrated. It opens an interactive list of every session and every window across all sessions — navigate with arrow keys, hit Enter to jump to any of them. Once you have three or four projects running simultaneously, Ctrl+B W is the fastest way to orient yourself and get exactly where you need to be.
I usually have one window per major task: one for the actual code, one for Claude Code running, one for logs.
Taking It Further: Scripted Startup
Once this workflow clicks, the natural next step is automating it. I have a PowerShell script that runs when I sit down to work. It:
- Opens a set of tabs in PowerShell — one per active project
- Colors each tab so I can tell them apart at a glance
- SSHes into the server
- Runs
tmux attach -t projectnamefor the right session in each tab
Starting work goes from several minutes of setup to one command. All my projects, sessions, and contexts are ready before I’ve made my coffee.
You can take this further on the server side too. A shell script that creates multiple named TMUX sessions, opens specific windows in each, and runs whatever startup commands you want (loading an environment, starting a dev server, etc.) makes a new machine feel like home in seconds.
PowerShell Over VS Code
I do all of this from PowerShell with multiple tabs, not VS Code with Remote SSH. VS Code is fine for local work, but for remote development I’ve found it adds more than it gives. It’s heavier than you need, and it has a habit of saying “Reconnecting to server…” at inconvenient moments.
PowerShell plus TMUX is lean. The only thing running is what you actually need. The only state that matters is on the server where it belongs. And when your connection drops, you just reconnect and reattach — no IDE rebuilding its index, no extensions re-initializing, no waiting.
Start Small
If you’ve never used TMUX, the move is simple: next time you SSH somewhere, run tmux new -s work before you do anything else. Spend a week working inside that session. Get used to Ctrl+B D to detach and tmux attach -t work to come back.
After a week you’ll add splits. After two you’ll have named windows. After a month you’ll write the startup script.
It compounds. The upfront investment is low; the habit pays back every single day.
One more pairing worth mentioning: if you run Claude Code on a remote server inside TMUX, Agent Vibes routes the agent’s audio output to your local speakers via SSH tunnel. TMUX keeps the session alive; Agent Vibes keeps you informed. Together they make remote agentic development feel genuinely hands-free.
Comments
Loading comments…
Leave a comment