Tmux Master

tmux-master

Fork, drive, and monitor long-lived CLI workers (Claude Code, Codex, bash) from another Claude Code session — each worker lives in its **own tmux session** so you can attach to it, send keystrokes, read its pane buffer, and terminate it cleanly.

• Global skill location: ~/.claude/skills/tmux-master/
• Registry: ~/.claude/state/tmux-workers.json (survives restarts)
• One worker = one tmux session (session name == worker name).
• Driver is environment-agnostic: main Claude Code can run inside tmux, iTerm, a VSCode terminal, anywhere — the helpers talk to the tmux server over its unix socket.

---

1. Motivation — why this exists

When a long task should run alongside the main Claude Code conversation, the usual options all have problems:

Option	Problem
File-based handoffs (.local/out)	Polling, stale reads, every side has to agree on a protocol.
Agent / Task subagents	Short-lived, single reply, no stateful REPL, no easy mid-task steering.
Launching claude / codex inline	Blocks the main session; output is interleaved; no clean kill.

`tmux-master` gives the main session a **live stdio channel** to each worker:

• Write keystrokes into the worker's pane (tm-send).
• Capture the worker's pane buffer on demand (tm-watch, tm-wait-idle).
• Kill the worker's entire process tree with one command (tm-close).

Concrete use cases it's built for:

1. Dual solver + evaluator — spawn a cc solver and a codex solver on the same task, wait for both, then run a bash evaluator worker.
2. Long research/crawl delegation — hand a multi-minute task to a worker, keep main responsive, poll when you need an update.
3. Human takeover — user can tmux attach -t from a