In one line. tickettok runs each Claude Code agent in its own detached tmux session and shows every agent's live status (RUNNING, WAITING, IDLE) on one auto-updating terminal dashboard, so you supervise a fleet instead of babysitting tabs.
Coding agents moved the bottleneck. Generating a change is now fast; the slow part is the human supervising the generators. Running one Claude Code session is easy, you watch it. Running five is where the workflow breaks: each lives in its own terminal tab, and the moment one stops to ask for permission, it sits there, blocked, until you happen to cycle back to that tab. tickettok turns that pile of tabs into a single kanban board where every agent's state is visible at once and updates itself.
Figure 1. Left: one terminal tab per agent, polled by hand. Right: the same agents on one board with statuses that update themselves.
📌 Honest scope, up front. tickettok's source is not public. The prebuilt binaries are free, installable via Homebrew, a shell script, or direct download from the releases repository. This write-up describes the architecture from the author's side; treat feature claims as documentation of the shipped binary, not of auditable source.
Terms in 30 seconds
Domain engineers: skip ahead, this is orientation for everyone else.
- Claude Code: Anthropic's CLI coding agent. It runs in a terminal, edits code, runs commands, and pauses to ask permission before sensitive actions. (docs)
- TUI (terminal user interface): an application drawn entirely inside the terminal, like
htop. - tmux: a terminal multiplexer. Sessions run detached in the background and survive independently of any window viewing them.
- PTY (pseudo terminal): the OS primitive that makes a program believe it is attached to a real terminal.
- Claude Code hooks: shell commands Claude Code executes at lifecycle events (prompt submitted, tool used, session stopped), configurable in
~/.claude/settings.json. - Kanban: a board of columns representing work states; items move between columns as their state changes.
Why this matters
- For anyone running agents in parallel: parallelism is the entire point of spawning multiple agents, and one unnoticed permission prompt silently collapses it back to serial. Making WAITING visible is the difference between five agents and one agent with extra steps.
- For the agent-tooling ecosystem: tickettok's substrate is plain tmux. Agents are ordinary tmux sessions you can attach to with or without the dashboard, so adopting it does not wrap your agents in a proprietary runtime.
- For multi-backend users: the same board supervises Claude, Gemini, and Codex CLI agents through one backend interface.
🧭 If you only read this far: tickettok makes a fleet of terminal coding agents legible at a glance, and it does it on top of tmux, so the agents never depend on the dashboard being alive.
The problem, for engineers who don't live in this space
Imagine a factory floor where every machine has its own status light, but each light is in a separate windowless room. The machines are fine; your legs are the bottleneck. That is multi-agent coding in terminal tabs: the agents are concurrent, but your attention is a single thread doing round-robin polling.
The concrete version: you spawn four agents on four tasks. Agent 2 hits a permission prompt ninety seconds in and stops. Nothing notifies you. The other three finish while agent 2 sat blocked for the whole session, and the wall-clock win you spawned four agents for evaporates.
Figure 2. Attention goes to the visible agent. The blocked ones wait, unseen, until you cycle through every tab.
Why this is genuinely hard. A dashboard needs to know each agent's state without owning the agent. Terminal programs do not expose "I am waiting for input" as an API; you either integrate with the agent's lifecycle (fast, precise, but agent-specific) or read what is on its screen (universal, but heuristic). Doing supervision well means solving both.
What exists today (and the gap)
| Approach | Live status at a glance | Agents survive the UI closing | Zoom to a full terminal | Diff review in an editor |
|---|---|---|---|---|
| One terminal tab per agent | ❌ manual polling | ✅ tabs are the terminal | ✅ | ❌ |
| Plain tmux windows | ❌ manual polling | ✅ | ✅ | ❌ |
| tickettok | ✅ auto-updating board | ✅ detached tmux sessions | ✅ keystroke passthrough | ✅ nvim pane |
Terminal tabs and raw tmux already give you persistence and full terminal access; what they lack is exactly the supervision layer: state detection, a board view, and alerts-by-visibility. tickettok adds that layer without taking the persistence away, because it builds on tmux rather than replacing it.
How it works
Each agent runs claude (or gemini, or codex) inside a detached tmux session named tickettok_<id>. The TUI is just a viewer and controller over those sessions.
- AgentManager: spawns, kills, discovers, and sends keys to agents; each is a tmux session plus metadata.
- PTY attachment: tickettok attaches a background PTY client to every session so tmux's
capture-panealways has rendered content to grab, even when no human is attached. - Views: a 2- or 3-column kanban board (IDLE, WAITING, RUNNING), a single-column carousel, and a zoom mode that forwards every keystroke to the agent's session, so zoom is the agent's terminal.
- State: persisted to
~/.tickettok/state.json, so quitting the TUI (agents keep running) and reopening it restores the board.discoveradopts already-running Claude instances it did not spawn.
Figure 3. The TUI drives an AgentManager; agents live in detached tmux sessions that outlive the dashboard, with board state persisted to disk.
Status detection, the heart of it
Status uses two paths, in order:
- Claude Code hooks (fast path): a shell script installed into
~/.claude/settings.jsonwrites a JSON status file to~/.tickettok/status/on each lifecycle event: prompt submitted, tool use, stop, permission prompt. The TUI's tick loop reads these files, so a state change appears on the board almost immediately. - capture-pane scraping (fallback): for agents without hooks (other backends, adopted sessions), tickettok parses the last 15 lines of the pane's output, looking for spinners, permission prompts, and idle indicators.
Figure 4. The hook path is event-driven and precise; the scrape path is universal and heuristic. Every agent gets whichever is available.
Editor integration
Pressing Ctrl+E on an agent opens an nvim pane beside it running claudecode.nvim, which speaks Claude Code's IDE protocol (MCP JSON-RPC over WebSocket). Claude's proposed changes appear as diffs you accept or reject inside nvim. The companion tickettok.nvim plugin is embedded in the Go binary via go:embed and installed with one command, tickettok nvim-setup, no plugin manager required.
The rest of the surface
Multi-backend support (Claude, Gemini, Codex) behind one Backend interface, workspace save/load, a git metrics overlay, batch operations, optional remote web control, JSONL transcript parsing for richer status, and self-update from GitHub releases. It is a single static Go binary built on Bubble Tea and Lipgloss; Windows runs it under WSL2, since tmux and Unix PTYs are hard requirements.
The decisions that actually mattered
tmux as the process substrate vs. owning child processes
The fork. The dashboard could spawn agents as its own child processes (full control, portable) or delegate to detached tmux sessions. Chosen. tmux sessions. Trade-off accepted. A hard dependency on tmux (and WSL2 on Windows), in exchange for the property that matters most: agents survive the dashboard crashing, restarting, or quitting, and any tmux user can attach to an agent directly with no tickettok involved. The supervisor is disposable; the work is not.
Dual-path status detection vs. picking one
The fork. Hooks are precise and near-instant but only exist where the agent supports them and the user installed them. Screen scraping works on anything with a terminal but is heuristic. Chosen. Both, hooks first, scraping as fallback. Trade-off accepted. Two detection paths to keep honest, in exchange for a board that stays accurate for hook-enabled Claude agents and still works for adopted sessions and other backends.
Embedding the nvim plugin in the binary
The fork. Ship tickettok.nvim as a normal plugin (users install it via their plugin manager) or embed it with go:embed and install it from the CLI. Chosen. Embedded. Trade-off accepted. A larger binary and plugin updates coupled to releases, in exchange for tickettok nvim-setup being the entire editor-integration install story.
Why this is significant
The narrow claim. tickettok does not claim a new algorithm. The contribution is a supervision layer for parallel terminal agents built on a deliberately boring substrate: agents as plain tmux sessions, state as JSON files, detection as hooks-plus-scraping. That shape means the dashboard adds legibility without adding a new point of failure between you and your agents.
Why it matters to the field. Running many coding agents at once went from novelty to daily workflow in roughly a year, and the tooling for supervising them is still being worked out across the ecosystem. The specific problems tickettok addresses (blocked-agent visibility, dashboard-independent agent survival, editor-grade diff review from a TUI) are the problems every team hits in week one of multi-agent work.
📌 Honest scope. Closed source; free prebuilt binaries. No adoption or benchmark numbers are claimed. The hook fast path currently targets Claude Code's lifecycle events; other backends rely on scraping. Editor integration depends on the third-party claudecode.nvim plugin.
What's next
Near-term, per the public docs: an auto-hiding editor pane (today AUTO mode behaves like ON, keeping the nvim pane open). Longer-term, tickettok sits in the same thread as in8's other agentic tooling, better-call-claude and dear-claude: agents are becoming coworkers, and coworkers need channels, dispatch, and, here, a manager's dashboard.
Appendix / references
- Install:
brew install sns45/tap/tickettok, orcurl -sSfL https://raw.githubusercontent.com/sns45/tickettok-releases/main/install.sh | sh, or a binary from GitHub Releases. - Status: closed source; free prebuilt binaries at sns45/tickettok-releases.
- Built with: Go · Bubble Tea · Lipgloss · creack/pty · tmux.
- Requires: tmux and the Claude CLI (WSL2 on Windows).
- Related in this series: better-call-claude (voice/SMS/WhatsApp for agents) and dear-claude (tickets that spawn local agents).