When a tmux script stops being enough

2026-09-10

You can get surprisingly far coordinating coding agents with tmux and some bash. Then one day you realize the real bottleneck is you.

---

You can get surprisingly far coordinating coding agents with tmux and some bash. Then one day you realize the real bottleneck is you.

You have multiple Claude Code or Codex sessions, each half-way through a task, and you’re alt-tabbing around trying to remember which one is stuck, which one is waiting on you, and which one quietly drifted off goal.

This is the point where “DIY multiplexing” stops being about panes and starts being about orchestration.

The line between "good hack" and "maintenance burden"

A tmux-plus-scripts setup is great for:

• Spawning multiple agent sessions quickly.
• Pinning each task to its own pane/window.
• Running simple broadcast commands (send-keys to a set of panes).

It starts to hurt when you need:

• A reliable view of which sessions are working, idle, blocked, or dead.
• A way to know what actually landed in git vs what’s still a draft.
• A control surface that doesn’t require you to remember every script name and flag.

At that point you’re not just multiplexing terminals; you’re running a small orchestration platform written in shell.

What tmux and scripts actually give you

If you’re reading this, you probably already have something like:

#!/usr/bin/env bash
SESSION="agents"

# create tmux session
if ! tmux has-session -t "$SESSION" 2>/dev/null; then
  tmux new-session -d -s "$SESSION" "claude-code run --task api-refactor"
  tmux split-window -t "$SESSION" "codex run --task write-tests"
  tmux split-window -t "$SESSION" "cursor-agent run --task docs-update"
  tmux select-layout -t "$SESSION" tiled
fi

# helper to broadcast a message
broadcast() {
  for pane in $(tmux list-panes -t "$SESSION" -F '#P'); do
    tmux send-keys -t "$SESSION":$pane "$1" C-m
  done
}

This works.

But as soon as you add:

• Per-pane status tracking.
• Logging and transcripts.
• Some notion of “session health”.

…you’re building a product. You inherit:

• Maintenance cost: every tweak is another script, another flag, another branch.
• Observability gaps: no first-class states, just whatever you script and remember.
• UX friction: knowledge of the system is in your head, not visible on screen.

The coordination bottleneck is now human, not model

The data backs this up.

• Stack Overflow’s 2025 survey: 84% of developers use or plan to use AI tools, 51% of pros use them daily, but only 3% “highly trust” the output.
• JetBrains’ 2026 survey: 90% of pros used AI coding agents weekly, 68% daily.

So your agents are on all day, but you still have to:

• Supervise.
• Validate.
• Decide.

Anthropic’s 2026 trends report calls this out directly: AI still needs “thoughtful set-up and prompting, active supervision, validation, and human judgment,” especially for high-stakes work.

A tmux script doesn’t change that; it just gives you more terminals to supervise.

What a real orchestration layer owns (and your scripts have to fake)

Tools like VS Code’s Agent Sessions, Cursor 3, and CommandSlate all converged on the same primitives:

• Multiple agents in parallel.
• Isolated worktrees/branches per task.
• A review surface for diffs, transcripts, artifacts.
• A single place to see live status.

If you roll your own orchestration on tmux, your scripts now own:

1. Session lifecycle
   • Spawning, naming, cleaning up agent processes.
   • Handling orphaned sessions and reconnects.

1. Status and health
   • Detecting “working” vs “idle” vs “blocked”.
   • Handling edge cases: crashed agent, lost network, auth failures.

1. Logging and observability
   • Per-session logs and transcripts.
   • A way to correlate output with git branches and tasks.

1. Control UX
   • Broadcast vs per-session commands.
   • Switching focus without remembering pane indexes and script names.

Microsoft’s own guidance on multiagent systems is blunt: orchestration adds coordination overhead, latency, and failure modes. Use the lowest-complexity pattern that reliably meets your requirements.

That’s the build-vs-buy line.

Where Maxxwell steps in: agent-of-agents, not another copilot

Maxxwell is a local desktop app plus CLI that sits above the agents you already run.

It does not replace Claude Code, Codex, Cursor, or your existing runtimes. Instead:

• Each worker is your existing tool, in a real terminal session. You can attach and take over at any moment.

• Every session carries a readable state: working, idle, waiting on you, blocked, needs sign-in, not started, done, dead, or not heard from, with a possibly stalled overlay when it looks suspect.

• There is an orchestrator seat at the top: itself a real agent session started from a written brief. You talk to it instead of twelve terminals, and it reports:
  • What landed (files, diffs, branches).
  • What it decided for you.
  • What still needs your call.

• Fleet controls draft rather than act: any control that would change the fleet writes a fully formed, unsent sentence into the composer. It never runs the command. You stay the one who presses enter.

• It runs locally, with no sign-up and no server. You bring your own model access: an API key or existing Claude/Codex/ChatGPT/Cursor setup.

If your tmux scripts are starting to look like an orchestration layer, Maxxwell is the “buy” side of that decision.

Build vs buy: maintenance

Building on tmux and Python/bash

You own:

• Process management: creating, naming, and killing agent sessions, handling orphaned tmux panes and zombie processes.
• Upgrade paths: every time Claude Code, Codex, or Cursor changes flags or auth, you hunt through scripts.
• Bug surface: race conditions in send-keys, lost logs, weird pane focus behavior.

Maintenance looks like:

# fix for orphaned sessions after ssh disconnect
for pane in $(tmux list-panes -F '#{pane_pid}'); do
  if ! ps -p "$pane" >/dev/null; then
    echo "Cleaning up dead pane $pane"
    tmux kill-pane -t "$pane"
  fi
done

Every corner case becomes more glue code.

Buying Maxxwell

You offload:

• Session lifecycle and persistence: quitting the app detaches sessions, it never kills them. Closing your laptop isn’t a decision to throw away an hour of work.

• State tracking: readable state and “not heard from” instead of guessing.

• Glue logic for new tools: workers are unmodified agents; Maxxwell doesn’t own their sign-in.

You’re still in control, but you’re not the one wiring process orchestration and recovery.

Build vs buy: observability

DIY observability

To get observability in tmux, you typically add:

• Pane naming conventions: api-refactor, write-tests, etc.
• Log files per pane (teeing output to logs/agent-*.log).
• Some status script that parses logs and prints a summary.

Maybe:

status() {
  for pane in $(tmux list-panes -F '#P'); do
    name=$(tmux display-message -p -t $pane '#{pane_title}')
    last_line=$(tmux capture-pane -pt $pane -S -1 | tr -d '\r')
    echo "$pane ($name): $last_line"
  done
}

Better than nothing, but fragile. Status is inferred from log tails, there is no notion of “waiting for you”, and the system has no idea what actually landed in git.

Maxxwell’s observability

Maxxwell gives you:

• A fleet view: one window listing all sessions with explicit states (working, blocked, etc.).
• A “possibly stalled” overlay on a session's state.
• A return report that separates:
  • What changed in the repo.
  • What is a proposal waiting on your approval.
  • What never started or died.

Every lane carries a readable state, and when Maxxwell cannot verify one it says not heard from instead of pretending things are fine.

That’s the difference between an observability layer and “I hope my log tail script is right.”

Build vs buy: UX and control

CLI UX: tmux + scripts

Your control surface is:

• tmux select-pane -t :1.2 or equivalent.
• A handful of scripts with names you have to remember: agent-broadcast.sh, agent-status.py, agent-kill.sh.
• Manual conventions: “pane 0 is always the orchestrator”, “top row is high priority”, etc.

It’s fast if you wrote it and live in it. It’s opaque to everyone else.

Maxxwell UX

Maxxwell treats UX as part of the product, not your job:

• One window instead of a dozen terminals, each session labeled with what it is doing.
• An orchestrator seat you brief in natural language instead of clicking around a control panel or juggling panes.
• Fleet controls that draft rather than act: nothing changes the fleet unless a person sends it.

You still have a real terminal per worker that you can attach to. The difference is you don’t have to memorize how the system works; you can read it off the screen.

Build vs buy: future extensibility

Extending a script farm

Want to add:

• Context-pressure warnings.
• Per-branch isolation with automatic merge queues.
• Different models per task.

You’re now:

• Designing your own agent orchestration API.
• Keeping your own metadata store (YAML, SQLite, whatever).
• Writing documentation so teammates can use it without breaking things.

This is fine if you want to build and maintain an orchestration platform. It’s not fine if you just want agents to stop wasting your attention.

Extending with Maxxwell

Maxxwell takes the orchestration layer as a given.

Within its claim boundary today:

• You get a live context-pressure readout with tiered warnings.
• You can compact context with one click when it gets too large.
• Sessions outlive the app; quitting just detaches.

You can layer your own workflows on top - branches, CI, review rules - but you don’t have to invent session management primitives.

Maxxwell vs tmux scripts vs IDE multi-agent views

Here’s the rough comparison.

If you’re still running a single agent at a time, tmux and your editor are enough.

If you’re juggling half a dozen sessions across tools and repos, a dedicated orchestrator like Maxxwell starts paying for itself in fewer lost hours and fewer sessions you have lost track of.

When you should keep your tmux scripts

It’s worth being explicit about where not to add a layer.

Stick with tmux and scripts when:

• You run at most one or two agent sessions at a time.
• Your tasks are short-lived and self-contained.
• You’re experimenting and don’t want any product in the loop yet.

In that world, a small script file is the right abstraction. Everything else is overhead.

Once you:

• Have 4-12 sessions open regularly.
• Find yourself the slowest part of the system.
• Can’t tell which session is stuck vs slow.

…you’re in the territory this article cares about.

For a deeper architecture view of this shift, see the pillar piece on agent-native development: a working definition, which treats “agents as first-class units of work” as a genuine architectural change rather than a UI change.

FAQ

When is a tmux script objectively not enough anymore?

When the complexity of maintaining the scripts exceeds the complexity of the work they’re coordinating.

Concrete signals:

• You have separate scripts for spawn, status, broadcast, kill, reconnect, logs.
• Teammates are hesitant to touch your setup.
• You’ve lost work because a pane or process died silently.

At that point, you’re running a homegrown orchestration platform.

Why not just use VS Code or Cursor’s multi-agent views?

You should, when your world fits inside their editor.

VS Code and Cursor both now have Agent Sessions views that act as a “single place” to manage local/background/cloud agents.

If you:

• Live mostly in one editor.
• Don’t need to treat agents as separate terminal processes you can attach to.

…those views are solid.

Maxxwell is for developers who already juggle agents across terminals, repos, and tools, and who don’t want their orchestration layer tied to one editor.

Does Maxxwell replace my tmux setup entirely?

No.

Maxxwell runs workers as real terminal sessions. You can still use tmux if you want, and you can attach to any worker session mid-sentence.

What it replaces is the coordination glue: state tracking, status dashboard, orchestrator, and the scripts you write to manage them.

How does Maxxwell avoid breaking my build quietly?

Two design choices:

• Workers are unmodified tools; Maxxwell doesn’t hide what they do. You can always attach to the underlying terminal.

• Fleet controls draft rather than act. A control that would change the fleet writes a fully formed, unsent sentence into the composer. It never runs anything without you pressing enter.

You stay the one who approves changes and merges.

What about automation: does Maxxwell auto-correct drift or restart work?

No.

The conducting is real; the autopilot is not.

Maxxwell does:

• Show context pressure with warnings and offer a one-click compact.
• Surface possibly stalled sessions.
• Persist work across app restarts.

It does not automatically detect drift and re-aim a session, automatically recycle context, restart work that stopped, or run a goal check on its own schedule.

Those decisions stay with you.

---