Someone asked me on Reddit why I use tmux instead of Warp. I tried Warp a year ago and again a few months ago. It’s fine. I wasn’t convinced.

The short answer: tmux is terminal-agnostic, and that matters more than people think.

I’m Not Attached to Any Terminal App

I started with screen, switched to tmux 10 years ago, and have used it across macOS Terminal.app, iTerm2, and now Ghostty. When I switched from Terminal.app to Ghostty a few months ago, I didn’t have to change a thing — except for a 1-liner configuration so I can use shift+enter to send newlines to Claude Code/Droid/Codex instead of alt+enter.

My sessions, my splits, my window layout — all of that lives in tmux, not the terminal. If Ghostty disappears tomorrow, I switch terminals and keep working. If Warp disappears, you lose everything that makes it Warp.

tmux Is the Glue for Coding Agents

I run multiple coding agent sessions — Droid, Claude Code, Codex — in tmux windows (aka “tabs”). Each agent gets its own tab. The agents understand tmux natively. I can tell an agent “look at tmux 3.1 for the backend process” and it knows exactly what I mean — session, tab, pane.

It’s how I coordinate multiple agents against the same repo:

  • One agent works on the frontend in tab 3
  • The backend API server runs with live reload in tab 4
  • Another agent works on the backend in tab 5, and I tell it to check the server output in tab 4 when things break

The agents can read pane contents, scroll back through history, issue commands in other panes, and re-run commands. They do this through tmux’s standard interface — tmux capture-pane, tmux send-keys. No special integration needed. I don’t even need to write a skill.

I also have a script that auto-renames tabs based on what each agent is doing. My status bar shows hb post draft, blue fix auth, wm refactor — not five tabs all named “droid”.

Warp’s AI features — command suggestions, error explanations, agent mode — are useful, but they’re a different kind of help. They make the terminal smarter. What I need is for my coding agents to orchestrate across multiple sessions, and that’s what tmux gives me. It also means I’m not locked into any particular terminal to get it.

A Small Set of Customizations That Last

I keep a small set of tmux keybindings that are consistent across tmux, Neovim, WebStorm, and Safari. ctrl-h and ctrl-l for previous/next tab. j/k for pane navigation. I set my tmux prefix to ctrl-w to match what I used in screen.

Not a lot to maintain, and it’s been stable for years. The beauty of tools like tmux — and I’m sure Warp too — is that as long as you don’t go overboard, the configurations can last for decades of productive work.

Someone told me they prefer Warp because it’s less to configure and they could never keep their dotfiles synced. Fair enough. But my tmux config is a handful of keybindings and a script that sets up my project tabs. It took 30 minutes to set up, once, years ago.

What About Warp’s Built-in Features?

Warp has nice things — command blocks, searchable history UI, inline AI. If you don’t use coding agents heavily, or you prefer an all-in-one experience, it’s a good terminal.

But I already have all of that through tmux + my agents. Copy mode gives me scrolling, paging, and search. tmux capture-pane pipes output wherever I want. And the AI part — I don’t need it baked into the terminal when I have full coding agents running in it.

The question isn’t really “tmux vs Warp.” It’s whether your terminal is the thing you’re building your workflow around, or just the thing your workflow runs inside. For me, it’s the latter. tmux is the layer that matters, and the terminal is interchangeable.