Back to news

Can you run multiple AI coding agents in tmux?

Short answer: you can, and it is the most common starting point: one tmux window or pane per AI coding agent, zero cost, everything in the terminal. It works well with two or three agents and starts charging you beyond that, for a reason you can verify in one command: tmux monitors silence per window, not per pane. Put three agents in three panes of one window, which is the arrangement almost everyone builds first, and tmux cannot tell you which one stopped.

Why is tmux the first setup everyone tries?

tmux is already installed or one command away, splits the screen into named panes, and the session survives disconnection: you can close the laptop and come back with your AI coding agents alive. For anyone running Claude Code or Codex over SSH on a server, it is the only reasonable option. Nothing below argues against starting there. It argues about what you hit later, and what to do about it inside tmux itself.

How do you set up one window per agent in tmux?

The arrangement that survives more than two agents is one window per agent, named after the job, rather than panes inside a single window. Named windows are what tmux can watch individually:

tmux new-session -d -s agents -n api
tmux new-window  -t agents -n web
tmux new-window  -t agents -n docs

for w in api web docs; do
  tmux set-window-option -t "agents:$w" monitor-silence 60
done

tmux list-windows -t agents \
  -F '#{window_name}  #{?window_silence_flag,IDLE,working}  #{t:window_activity}'

The last command is the closest thing tmux gives you to a status board. It prints one line per agent, the word IDLE when that window has produced no output for 60 seconds, and the timestamp of its last activity. Start your agent inside each window (tmux send-keys -t agents:api 'claude' C-m) and you have a list you can re-read in one glance instead of switching pane by pane. Run it on a loop with watch, or bind it to a key, and it becomes a poor man's dashboard.

Why does tmux not tell you which agent stopped?

Because the unit tmux watches is the window. monitor-silence is a window option and window_silence_flag is a window format; there is no per pane equivalent. The consequence is easy to reproduce: split one window into two panes, keep one busy and leave the other completely silent, and ask tmux how things are going.

tmux new-session -d -s mixed
tmux split-window -h -t mixed
tmux set-window-option -t mixed monitor-silence 5
tmux send-keys -t mixed.0 'while true; do echo tick; sleep 1; done' C-m
sleep 9
tmux list-windows -t mixed -F 'silence_flag=#{window_silence_flag}'
tmux kill-session -t mixed

It prints silence_flag=0. One agent is stalled and tmux reports the window as healthy, because the other pane is still writing. That is the whole limitation in one number, and it is why the pane grid that looks so good in a screenshot is the arrangement that hides a stuck agent best. One agent per window costs you the grid and buys you the alarm.

What tmux still will not do

Silence is not the same as being stuck. An agent waiting for you to approve a file write is silent, an agent thinking for two minutes is silent, and an agent that crashed is silent forever. tmux measures bytes on a terminal, so it cannot separate those three, and none of the built in alerts know the difference between "asked you a question" and "finished the job". The visual alert also needs a client attached to the session; on a detached session the flag is still readable by the command above, but nothing pops up on its own.

Claude Squad: tmux taken to its limit

Claude Squad is the best known answer inside the terminal: a TUI that manages several sessions of Claude Code, Codex, OpenCode and Amp, using tmux underneath and isolating each instance in its own git worktree. The repository at github.com/smtg-ai/claude-squad shows 8,304 stars and its last push on July 30, 2026, read on August 13, 2026. It requires tmux and the GitHub CLI. It solves session creation and switching, and it moves the unit of isolation to the worktree, which is the right move. Observation stays textual: the list tells you which sessions exist, not which one needs you right now.

When is tmux still the right choice?

On a remote server with no graphical interface, tmux remains unbeatable, and the window per agent recipe above is the best you can do there. It also wins when the budget is zero, when the workflow is one hundred percent keyboard, or when company policy forbids installing apps. With one or two AI coding agents, any setup works: the problem panel apps solve only appears when a third agent starts running while your attention is on the first.

What to use when tmux stops being enough

The category that grew through 2026 is the panel app: each AI coding agent in its own panel, with a real terminal inside, state visible from across the room and a notification when an agent asks for help. CanvasCode, for macOS, reads state through the CLI's own hooks (working, waiting for you, done, crashed), which is the distinction tmux structurally cannot make, and notifies you even when the agent that needs you lives in another project. Six agents on one screen is normal use. The limitation to weigh: it is a Mac desktop app and does not run on a remote server over SSH the way tmux does.

Can you mix tmux and a panel app?

You can, and it is a common arrangement: the terminal inside each panel is a real terminal, so nothing stops you from opening an SSH session with remote tmux inside it. The agent runs on the server, and the local layer handles what tmux does not: state that separates waiting from working, notifications, and per project organization. The choice is not binary; it is about where each layer works best.

What this was tested on

Every command above was run on tmux 3.6a on macOS on August 13, 2026, and the outputs quoted are the ones it printed. Behaviour of monitor-silence has been stable across tmux 3.x, but if you are on an older build, check tmux -V and confirm window_silence_flag exists before relying on it. The 60 second threshold is arbitrary: pick it from how long your agents normally go quiet while thinking, because too low turns every pause into a false alarm.