Tmux for Agentic Coding: Run Multiple AI Sessions Without Losing Control

0:00 Welcome to Learning Podcasts. tmux for Agentic Coding. You start one Claude Code session to fix the backend. You start Codex in another terminal to investigate a test. A dev server is printing logs somewhere. A watcher is rerunning the suite. 5 minutes later, you have 6 terminal tabs and no idea which one owns the work. Right. The bottleneck is not launching the agents. The bottleneck is supervising them. Once coding agents become long-running workers in your terminal, you need a control plane for the terminal itself.

0:29 A coding agent is not shaped like `ls` or `pytest`. It reads files, asks for permission, edits code, runs commands, changes its plan, and keeps context in the conversation. That is the part people underweight. The agent session is stateful. If you lose the terminal, mix its output with another task, or forget what it was allowed to touch, the model quality is not the only problem anymore. Exactly. Treat the agent less like a command and more like a supervised worker. It has a task, a workspace, a transcript, and a current state.

1:08 tmux gives you a place to keep that worker visible. The tmux hierarchy is simple enough. A session is the project workspace. A window is a workstream. A pane is one visible process inside that workstream. So the session might be `payments-refactor`. The windows might be `main`, `agent-api`, `agent-tests`, `server`, and `review`. Exactly. That is the move. You stop thinking, "I have a bunch of terminal tabs." You start thinking, "this project has named workstreams, and each workstream has a clear job."

1:46 Which sounds small until an agent has been running for 30 minutes and you need to know whether it is blocked, done, or quietly rewriting the wrong file. Classic. It is funny because it is avoidable. The hierarchy makes the supervision surface explicit. You do not need a heroic tmux configuration to get value. Start a named session. Attach to it. List sessions. Detach without killing the work. Create windows. Split panes only when the extra visibility helps. The default muscle memory is enough: create a named session, detach with the prefix plus `d`, create a new window with the prefix plus `c`, split panes with the prefix plus percent or quote, move around with next and previous window, and enter scrollback with the prefix plus left bracket.

2:40 And the important word there is named. A session called `0` is technically valid, but it tells future you nothing. A session called `checkout-api-agent` is a note to yourself. A useful local layout has one boring human window called `main`. That is where you run Git status, inspect diffs, and make integration decisions. Then give each agent its own named window. Maybe `agent-auth` owns authentication cleanup. Maybe `agent-tests` owns a failing test investigation. Maybe `agent-ui` owns one small frontend change.

3:17 Keep dev servers and watchers separate. A test watcher should not share an output stream with an interactive agent. A server log should not scroll your approval prompt off the screen. Yeah. I have absolutely approved something in the wrong terminal because a log line moved the interesting part away. That is not a model problem. That is a cockpit problem. Here is where it gets really useful. The layout only helps if the responsibilities are real. Three agents editing the same module from three panes is not parallelism.

3:50 It is a merge conflict with better branding. Right. Split by ownership. One agent can inspect tests. Another can update UI copy. Another can draft a migration plan. But if two agents both own the same file range, tmux cannot save you. That is where the human stays the coordinator. You decide which windows exist, what each one is allowed to touch, and when an agent needs to stop because the repo changed underneath it. This is the unglamorous part of agentic coding. Autonomy without ownership boundaries just creates a faster mess.

4:28 I love that, because the name becomes part of the guardrail. Window names are not decoration. They are operational labels. `agent-one`, `stuff`, and `new` are tiny lies you tell yourself. A good name carries scope and risk. For example, `codex-fix-login-test`, `readonly-api-audit`, `server`, `review`, and `danger-db-migration`. The name should answer two questions when you glance at the status line. What is this process trying to do. And what is it allowed to touch. That second question matters.

5:00 If a window is called `readonly-audit` and it starts editing files, the mismatch is visible immediately. You have created a cheap tripwire. Exactly. tmux scrollback is underrated. Agent sessions contain decisions, failed attempts, command output, permission prompts, and little warnings that matter 20 minutes later. Without scrollback, you end up relying on memory or on whatever the agent summarized at the end. And the final summary is not always the best audit trail. Copy mode lets you search backward, copy the exact traceback, or find the moment an agent changed direction.

5:36 That is useful when the diff looks surprising and you want to know why it made that choice. It is not a substitute for Git history or logs. But it is the closest thing to a live operations notebook for the terminal session. Right. And this is where the tidy layout can become dangerous. Here is the boundary that prevents a lot of pain. tmux organizes processes. It does not isolate the files they edit. If two panes are in the same checkout, they are touching the same working tree. The status line may look tidy while the filesystem is quietly shared.

6:11 So use Git discipline. Run status often. Stage by explicit path. Avoid broad adds when several sessions are active. Inspect the combined diff before you believe any one agent's success story. And when the work is truly independent or risky, use Git worktrees. tmux gives each agent a window. A worktree gives it a separate checkout. Those solve different problems. That distinction is the difference between organized parallel work and organized confusion. Locally, tmux is mostly organization. On a remote box, tmux becomes reliability.

6:48 Exactly. If you are SSHed into a beefy development machine, a GPU box, or a cloud instance, the fragile part is the SSH client. Wi-Fi drops. The laptop sleeps. The terminal crashes. The agent should not die because your network hiccuped. Run the agent inside tmux on the remote machine. Detach before you disconnect. Reattach later from the laptop. The process belongs to the remote tmux server, not to the one SSH window that happened to start it. That is the remote-work superpower. Long-running agents, test suites, logs, and servers survive the connection that launched them.

7:28 This is the part that feels wrong until you try it carefully. The remote story gets even more interesting from a phone. With Termius or a similar SSH client, you can reattach to the same tmux session and check the work without opening a laptop. But the phone is a supervisor console, not a code review station. Exactly. Good phone tasks are narrow. Is the agent blocked. Did the test finish. Does it need permission to run one safe command. Did it produce a final summary. Should I detach and let it continue.

8:03 Bad phone tasks are the scary ones. Approve a broad rewrite. Review a giant diff. Push to remote. Accept a destructive command because the tiny screen made it look harmless. The phone is for keeping work unblocked, not for pretending a 5-inch display is a senior review surface. On a laptop, panes can be great. You can watch an agent and a test runner side by side. On a phone, that turns into terminal confetti. So bias mobile sessions toward windows, not panes. One window for the agent. One for tests.

8:38 One for server logs. One for Git. Switch windows instead of trying to read a four-pane dashboard through a keyhole. This is also why names matter more on mobile. You cannot rely on spatial memory when everything is full screen and tiny. The window name becomes the map. And if a process needs real visual comparison, do it later on the laptop. Mobile supervision is about state, not depth. Right. You can get far with stock tmux, but a few settings pay for themselves. Larger scrollback history. Mouse mode if you like clicking panes and scrolling.

9:12 Vi-style copy mode if your hands already think that way. And on macOS, clipboard integration matters if you frequently copy tracebacks or agent summaries out of tmux. Otherwise you do the weird dance where the text is technically copied, but not where the rest of the system can paste it. The point is not to build a beautiful dotfile. The point is to remove friction from supervision: find the old output, copy the exact error, move to the right window, detach cleanly. Minimal config is a feature when you jump onto a new remote box.

9:42 The more custom your setup is, the more helpless you feel when the defaults are all you have. Right. This is the discipline piece. tmux makes it easy to keep agents running. That does not mean every agent should run unattended until it declares victory. Use checkpoints. After the plan, inspect the intended scope. After the first meaningful diff, check whether it touched the right files. When tests fail in a new way, decide whether the agent should continue or stop. Before a commit or push, review like you would review a teammate's work.

10:16 The checkpoint is not bureaucracy. It is where the human catches stale context, wrong ownership, and "technically green but obviously not what we asked for." Exactly. tmux keeps the worker visible. It does not absolve the supervisor. Oh, man. The failure modes are very recognizable. The failure modes are predictable. Poorly named sessions. Too many panes. Agents sharing one checkout when they should have separate worktrees. Watcher output hiding permission prompts. A phone approval for a change that deserved a real screen.

10:52 And the sneaky one: stale context. One agent finishes a refactor, another agent in a different window is still reasoning from the old file layout, and you let it continue because the terminal looks calm. That is why the sweep matters. Move through the windows. Ask what changed. Kill or restart stale sessions. Rebase the mental model before you rebase the branch. The goal is not more terminals. The goal is less mystery. So the durable mental model is simple. tmux is the cockpit for agentic coding.

11:29 It gives you named workstreams, durable sessions, inspectable scrollback, remote survival, and mobile check-ins. And it has a clear boundary. tmux does not replace Git, worktrees, CI, code review, or judgment. It just keeps the agent work visible and recoverable long enough for those things to do their job. Once you see agent sessions as supervised workers, the terminal needs structure. tmux is the smallest serious structure that works locally, over SSH, and from a phone. Thanks for listening to Learning Podcasts.