MuxAgent vs. manual SSH and tmux: when a control plane pays for itself

If you are already running AI coding agents on remote machines, you probably started with SSH and tmux. Most developers do. You SSH into the box, start a tmux session, fire up your agent, and detach when you need to step away. The workflow is familiar, reliable, and requires nothing new.

This is a genuinely good starting point. SSH gives you a secure shell to any machine you control. Tmux gives you persistent terminal sessions that survive disconnects. Together they handle the basic problem of running long-lived processes on remote machines. If you are running a single agent on a single machine and you are always near a laptop with SSH access, there is no reason to add more tooling.

The question this post addresses is what happens when the work grows beyond that baseline — more machines, more sessions, more situations where you are away from your laptop when a decision needs to be made. Not because SSH and tmux stop working, but because the overhead of coordinating everything manually starts eating into the time the agent is supposed to save you.

The manual approach: what it actually looks like

Let’s be concrete about what managing agents through SSH and tmux involves day to day.

You have a dev server running an AI coding agent — say Claude Code or Codex — on a refactoring task. You started it in a tmux session before lunch. Now you want to check on it.

ssh devbox
tmux attach -t agent-session

You see the output. The agent has finished planning and is waiting for you to confirm the approach. You review, approve, and detach:

# review the plan output...
# type "yes" or similar to approve
Ctrl-b d  # detach

That works. For one session on one machine, the workflow is direct and transparent. You can see exactly what the agent is doing because you are looking at its terminal output.

Now scale that up. You have three machines: your laptop for quick tasks, a workstation for builds that need more CPU, and a dev server for long-running migrations. Each has one or two active agent sessions. Some of those sessions are paused waiting for approval. Others are running.

Your workflow becomes:

# Check workstation
ssh workstation
tmux ls                    # Which sessions are active?
tmux attach -t refactor    # Check on the refactoring task
Ctrl-b d
tmux attach -t migration   # Check on the migration task
Ctrl-b d
exit

# Check dev server
ssh devserver
tmux ls
tmux attach -t codex-review
# ...

This is manageable if you are sitting at your laptop and have time to cycle through machines. But consider the following situations:

You are in a meeting. An agent on your workstation has finished its plan and is waiting for approval. You do not know this because you are not attached to that tmux session. The agent sits idle until you return to your laptop, SSH in, and check. That might be thirty minutes. It might be two hours.

You are commuting. Your phone is the only device you have. SSH from a phone is technically possible but practically miserable — small screen, awkward keyboard, no scrollback. You are not going to review a 200-line plan diff on a phone terminal.

A session crashes. The tmux session on your dev server died because the machine rebooted overnight. You discover this the next morning when you SSH in. The agent’s work-in-progress is gone. You restart the task from scratch, losing the work already done.

You need to coordinate across machines. A migration task started on your workstation needs verification on the dev server. You SSH into the workstation, check the status, note what to verify, SSH into the dev server, and run the checks. The coordination is entirely in your head.

None of these are SSH or tmux failures. They are doing exactly what they are designed to do. The gap is that managing agent workflows requires an operational layer that terminal multiplexers were never built to provide.

Where manual management breaks down

The problems with manual SSH and tmux management cluster around a few themes.

Visibility is pull-based, not push-based

With tmux, you see what an agent is doing only when you actively attach to its session. There is no notification when an agent finishes a phase, encounters an error, or needs approval. You have to remember to check, and you have to be at a device where checking is practical.

This matters because the value of AI agents depends on turnaround time. An agent that finishes planning in five minutes but waits two hours for approval is not saving you time — it is creating a queue that you drain manually every time you remember to check.

Session recovery is manual

Tmux sessions persist as long as the tmux server process is running. If the machine reboots, the tmux server restarts, or the session is killed, the terminal state is gone. There is no built-in way to recover the agent’s position in a multi-step workflow.

In practice this means that a reboot or crash forces you to restart the task from scratch. For a five-minute exploratory task, that is fine. For a multi-hour migration that was in its verification phase, that is expensive.

Multi-machine coordination is ad hoc

If you run agents on multiple machines, you need a way to know which machine has which tasks, what state each task is in, and which tasks need attention. With SSH and tmux, that coordination lives entirely in your memory or in notes you maintain manually.

There is no centralized view of all your running sessions. There is no way to see “machine A has two sessions paused at approval, machine B has one session running, machine C is idle” without SSHing into each one and checking.

Approval workflows do not exist

Tmux has no concept of workflow stages. It gives you a persistent terminal, and what happens inside that terminal is up to the agent and your typed input. If your agent framework supports approval gates (like MuxAgent’s graph-based workflows), the approval still happens by typing into the terminal — which requires being attached to the session.

This is workable for simple tasks where you are actively watching. It falls apart when you want the discipline of explicit plan review and approval on important tasks but cannot always be at the terminal when the agent reaches those checkpoints.

What a control plane adds

A control plane like MuxAgent sits between you and your agent sessions, providing three things that SSH and tmux do not:

Push-based visibility. Your mobile app shows all active sessions across all machines in one place. When an agent reaches an approval checkpoint or finishes a phase, you see it immediately. You do not need to remember to check — the work comes to you.

Structured workflows. Agent tasks run through explicit graphs with planning, review, approval, implementation, and verification stages. The workflow is defined in configuration, not improvised in a terminal. This means approval checkpoints work even when you are away from the machine — you review and approve from your phone.

Session persistence above the terminal layer. Session metadata (ID, machine, working directory, status, cost) is stored in the CLI’s local database and synced to the mobile app via the encrypted relay. If the WebSocket connection drops, only the encrypted channel is lost — not the session data. Reconnection re-establishes the secure channel and resyncs events.

Multi-machine management from a single device. The mobile app connects to all your machines through the relay. You can see sessions on your workstation, dev server, and laptop from one screen without SSHing into each machine separately. Starting a new task on a specific machine is a matter of selecting it in the app. Explore how multi-machine workflows work.

The way MuxAgent implements this is through its daemon and relay architecture. Each machine runs muxagent daemon start, which connects to the relay over WebSocket. The mobile app also connects to the relay. Communication is end-to-end encrypted — the relay routes encrypted traffic but cannot read the content. This means you get the convenience of a centralized view without giving a third party access to your source code.

When the manual approach is fine

To be fair about when SSH and tmux are the right choice:

Single machine, single agent. If all your agent work happens on one machine and you are usually at your desk when you need to check on it, the overhead of a control plane does not pay for itself. Just attach to the tmux session.

Short tasks you actively supervise. If your typical agent task takes ten minutes and you watch it the whole time, there is no gap where push notifications or mobile access add value.

No approval workflow needed. If you run agents in fully autonomous mode and trust them to complete without human checkpoints, the workflow management features of a control plane are irrelevant. You just need the terminal output.

Single-user, no coordination. If you are the only person who will ever interact with these agents and you do not need to coordinate across machines, the centralized view is less valuable.

In these cases, SSH and tmux do the job with zero additional tooling. The simplest approach that works is the right approach.

When a control plane pays for itself

The crossover happens when the manual approach starts creating queues — moments where work is blocked because a human is not in front of the right terminal.

Multiple machines. Once you have agent sessions on two or more machines, the cost of cycling through SSH connections to check status becomes a friction you feel daily. A unified view across machines eliminates that.

Important tasks that need approval. If you structure your tasks with explicit plan review and approval, those checkpoints need to be reachable when you are away from the terminal. Mobile access turns approval from “whenever I remember to check” into “as soon as the agent is ready.”

Work that spans hours or days. Long-running migrations, large refactors, or multi-phase tasks are exactly the scenarios where you will be away from the terminal when something needs attention. The longer the task, the more likely the manual approach creates an idle queue.

Away-from-desk time. If you commute, take meetings, or simply step away from your computer regularly, any agent work that needs human input during that time is blocked in the SSH and tmux model. The control plane makes that time productive instead of dead.

Team environments. If multiple people need visibility into running agent tasks — for coordination, handoff, or oversight — a shared terminal session is not a real solution. A control plane provides the shared state that makes multi-person agent operations practical.

The practical difference

Here is the same scenario in both approaches:

Manual SSH + tmux: You start a refactoring task on your workstation before a meeting. During the meeting, the agent finishes planning and waits for approval. You return 90 minutes later, SSH in, attach to the tmux session, review the plan, approve it. The agent starts implementing. Total idle time: 90 minutes.

With MuxAgent: You start the same task using muxagent on your workstation. During the meeting, you glance at your phone and see the agent has finished planning. You review the plan diff in the mobile app during a break, approve it. The agent starts implementing. Total idle time: 5 minutes.

That 85-minute difference is not theoretical. It compounds across every task that hits an approval gate while you are away. Over a week of running three or four tasks a day, the accumulated idle time from manual management is significant.

The control plane does not make the agent faster. It makes the human faster — specifically, it removes the latency between “agent needs input” and “human provides input.” That latency is where manual management creates its hidden cost.

Migration path

If you are currently using SSH and tmux, the migration to MuxAgent is incremental. You do not need to abandon your existing setup.

1. Install the CLI on one machine: curl -fsSL https://raw.githubusercontent.com/LaLanMo/muxagent-cli/main/install.sh | sh
2. Start the daemon and pair: muxagent daemon start triggers auth if needed — scan the QR code with the mobile app
3. Run a task through the control plane to see the difference: muxagent launches the task TUI with workflow configuration selection
4. Keep tmux for the sessions that don’t need the control plane — they coexist without conflict

You can keep SSH and tmux for quick, supervised tasks and use MuxAgent for the tasks that benefit from structured workflows and mobile access. The two approaches are complementary, not mutually exclusive.

Conclusion

SSH and tmux are not broken. They are excellent tools for their intended purpose. The question is whether managing AI agent workflows is still that purpose once you have multiple machines, long-running tasks, and time away from the terminal.

A control plane like MuxAgent adds value precisely where the manual approach creates idle time: when you are away from the machine, when approval is needed, and when coordinating across machines. For developers whose agent work stays on one machine with constant supervision, the manual approach is fine. For everyone else, the structured workflow and mobile access eliminate a friction that compounds daily.

The right answer depends on how you actually work, not on which tool is theoretically more capable.