Claude Code and tmux

The standard advice for running several Claude Code sessions is to put them in tmux, and there's a whole family of tools built on that assumption. It's reasonable advice and I want to be fair to it before I explain why I don't do it.

What tmux is genuinely good at here

If you work on a remote machine over SSH, this isn't really a debate. Your sessions have to survive the connection dropping, tmux does that, and nothing about terminal tabs helps you when the terminal is on your laptop and the work is on a box in a data centre. Same if your development environment is a devcontainer or a cloud VM you attach to.

Beyond that, tmux gives you a scriptable layout, so you can define a fleet as a config file and bring the whole thing up with one command. It gives you panes visible side by side, which some people genuinely think better in. And it's already installed and already configured for a lot of engineers, which is worth more than it sounds, because the best tool for coordinating your work is frequently the one you don't have to learn this week.

What it costs once you're at fleet scale

The thing you do most often when running a lot of agents is read output, which surprises people who assume the job is mostly writing prompts or arranging windows. You read what an agent just did, decide whether it's on track, and move on. At twelve streams I'm doing that dozens of times an hour, most of it a quick scroll back through the last screen or two, plus a fair amount of copying an error out of one session to paste into another.

tmux sits between you and both of those. Scrollback goes through copy mode, mouse selection needs configuration and then behaves differently from every other window on your machine, and copying a stack trace out of a pane is a small negotiation rather than a drag. Individually these are seconds. Multiplied by the number of times a day you do them, they're the difference between a practice that feels smooth and one that feels like friction, and friction is what makes people quietly stop running eight sessions and drift back to three.

The second cost is that a tmux grid gets small. Four panes on a laptop screen means four narrow columns, and Claude Code output is wide: diffs, file paths, tables. You end up either squinting or zooming a pane to full screen, and once you're zooming panes to full screen you have reinvented tabs with extra steps.

The tabs alternative

My terminal already had a multiplexer in it, and so does yours: tabs. One tab per session, named for the work it's doing. Full-width output, native scrollback, native copy and paste, and the tab bar as the fleet overview.

The piece that doesn't come for free is the bookkeeping, which is what cctabs does: spawning named tabs, keeping the tab title and the Claude session name in sync, re-attaching everything after a reboot, forking a session into a new tab, and letting one session read and write another's terminal so Claude can drive the fleet itself.

npm install -g @generativereality/cctabs

cctabs new auth ~/Dev/myapp --worktree
cctabs sessions
cctabs scrollback auth

It works in Wave Terminal out of the box and in Tabby with a one-time plugin, on macOS and Linux, and under WSL2 on Windows.

Where Agent View changed the question

Anthropic have since shipped Agent View, opened with claude agents, which their docs describe as "one screen for all your background sessions: what's running, what needs your input, and what's done". Sessions dispatched from it run under a supervisor process rather than being attached to your terminal, and the docs are explicit that "you can close agent view, close your shell, or start a new interactive session and your dispatched work keeps going."

That quietly takes the persistence argument away from tmux for a whole category of work. If your reason for reaching for tmux was so that a long-running task survives you closing the terminal, that's now built in and you should just use it.

What it deliberately isn't is a terminal multiplexer, and its sessions aren't terminal-attached at all. So it doesn't help with the one to three streams that need to be in front of you — the dev server you're clicking through, the browser automation you're watching, the conversation where you're iterating with the agent because the problem needs you. Those still want a real terminal you're looking at.

Picking one

Roughly how I'd choose, if I were starting today:

• Working over SSH, or on a remote box or VM. tmux, or Agent View for anything that can run in the background. Terminal tabs on your laptop don't help you here.
• Mostly dispatching background work and checking on it later. Agent View. It's built in, it survives your shell closing, and it's a shorter path than installing anything.
• Local machine, several streams you're actively QAing, lots of reading output. Terminal tabs, with cctabs doing the bookkeeping. This is the one I run.
• You already have a tmux config you love. Keep it. The reading-output tax is real but it isn't fatal, and switching terminal habits mid-practice costs more than it returns.

Worth clearing up one thing that gets conflated: none of this has anything to do with worktrees. Whether your sessions live in panes, tabs or a supervisor process, two agents editing different branches still each need their own working directory, and that's a git question rather than a terminal question. The parallel-sessions guide covers it, along with the worktree base-branch gotcha that catches most people once.

Where to go next

• Running Claude Code sessions in parallel — what breaks between three sessions and twelve.
• What is AgentHerder? — the practice, and the tool.
• The AgentHerder Course — six weeks of the practice, free.