tmux-agent-control

Topics in the source

• Controlling a live TUI agent in tmux
• When to Use
• Pick the control mode first
• Procedure
• Process lifecycle & graceful shutdown
• Pitfalls

Driving a coding agent (omp, pi, opencode, claude-code) that someone left running in a tmux pane: read its state, wait for it to go idle, then hand it the next instruction without corrupting the session. the operator says "watch that agent and tell it X when it finishes" / "take over the session in tmux" you must monitor a long agent turn and report its real outcome a multi-phase delivery (goal → simplify → review → PR → babysit → merge) runs through a driven agent → follow goal-driven-delivery and use this skill for the mechanics NOT for one-shot generation — that is headless pi -p / omp -p ... @prompt.md > out.md (see omp-headless-orchestration); never route a one-shot through tmux Existing interactive pane the operator may also be using → drive it in place (this skill). New task, no steering needed → headless omp -p with the prompt in a file, output to a file. New task needing multi-turn steering → own detached session: tmux new-session -d -s agent-dev -c , then the same protocol. Never start a second agent in a repo that already has one mid-turn: two writers on one working tree produce a diff nobody can attribute. 1. Locate the pane by process, not by a remembered session name.

This is an excerpt. Refer to the complete source and its current requirements.