Terminal persistence becomes agent infrastructure
Tmux is increasingly being used as a lightweight control surface for terminal-based coding agents. A new technical guide by developer Crystal outlines why: named sessions survive a closed terminal or dropped SSH connection, multiple tasks can share one server, and external scripts can send input to or capture output from individual panes.
For a single Claude Code task, the guide points to the tool's built-in worktree and tmux options. The --tmux option is tied to --worktree, creating an isolated branch workspace and a session together. On iTerm2, the command may use native panes instead; users who need an actual tmux target for automation can request classic mode.
Beyond that built-in case, operators often assemble their own conventions. The guide recommends one named tmux session per repository, with transient agent tasks placed in windows inside it. Windows keep inactive tasks out of the current layout, while panes work for the few agents a developer wants to watch side by side. Preserving each pane's current path is important so a newly launched agent starts in the intended repository.
Scripting is useful and brittle
Tmux's send-keys command can inject a prompt or interrupt a running process. The guide recommends literal mode for text so words such as Enter or Escape are not interpreted as key names, followed by a separate newline. Some terminal interfaces need a short interval between pasted text and submission to avoid swallowing the action during a redraw.
The reverse operation, capture-pane, returns the rendered contents of a pane. Joining wrapped lines is important when scripts search the captured text; otherwise a match can be split at the terminal boundary. pipe-pane can provide a continuous stream, although its output includes terminal escape sequences and needs cleaning for readable logs.
These techniques enable simple dashboards that look for signs an agent is working or waiting. They are not a reliable state protocol. A status line that periodically scrapes rendered text depends on wording that may change between agent versions. tmux activity or silence monitoring is lighter, but silence can mean completion, a blocked prompt or a long computation.
Persistence also has limits. A tmux server survives disconnection because it owns the pseudo-terminals, but it does not inherently survive a machine reboot. Scrollback disappears when the server stops unless output is streamed elsewhere. Sessions also lack the durable task metadata, structured completion events and policy controls expected from a purpose-built orchestration service.
The result is a useful middle layer. tmux can keep a handful of agents organized, script routine interaction and reduce the cost of lost connections. As concurrency grows, its screen-oriented interfaces and inferred status become the ceiling. Teams can use it effectively when they recognize that it manages terminals, not the underlying lifecycle and correctness of autonomous work.
