agtx: a terminal kanban board for running Claude Code, Codex and Grok in parallel

What agtx solves for people who already live in a terminal

Running one coding agent is a single shell command. Running four of them across three repositories is a bookkeeping problem: which session is on which task, which one is waiting for a permission prompt, which one finished and needs review. agtx answers that with a kanban board drawn in the terminal. The README describes it as "a blackboard for coding agents" and lists the agents it can drive: Claude Code, Codex, Grok, Cursor, OpenCode, Antigravity, Gemini CLI, Copilot and pi. The board holds tasks across multiple projects, and each task moves through workflow phases. The intended audience is narrow and specific: developers who are comfortable in tmux and Vim, who keep their projects in git, and who treat the agent as a process they supervise rather than a chat window they type into. The README is explicit that the board is multi-project, so a single TUI can show sessions from more than one repository at once. That is the actual product claim. Everything else in the README, the plugins, the skills, the MCP server, hangs off that board.

How the board, tmux sessions and per-phase agents fit together

The mechanism is visible in the requirements and the dependency list. Agent sessions run in a dedicated tmux server, so agtx is a controller on top of tmux rather than a replacement for it. The TUI is built on ratatui and crossterm, and the binary is Rust with a bundled SQLite through rusqlite, which is where task state lives. The README tells you to add `.agtx/` to your project's `.gitignore` "to avoid committing worktrees and local task data", which confirms two things: agtx creates git worktrees per task, and it writes local task data into that directory. The parallel lifecycle is the part worth reading twice. You configure different agents per workflow phase, so Grok can do research, Claude can implement, and Codex can review, with what the README calls automatic agent switching and context handover. A task therefore is not bound to one model for its lifetime. It is bound to a phase, and the phase decides which agent picks it up. An MCP server is included through rmcp, and the experimental orchestrator agent uses it to manage the board itself: delegating to coding agents, advancing phases and checking for merge conflicts. The README labels that orchestrator experimental, and that label should be taken literally.

Installing agtx and creating the first task

The README gives a one-line installer. It pipes a shell script from the repository's main branch into bash, so read the script before you run it if that pattern bothers you; the file is `install.sh` at the repository root.

curl -fsSL https://raw.githubusercontent.com/fynnfluegge/agtx/main/install.sh | bash

If you would rather build it yourself, the README documents a Cargo build with the serve feature, which is what adds the mobile board. The published binaries are built with that feature enabled.

cargo build --release --features serve
cp target/release/agtx ~/.local/bin/

Before any of this works, tmux has to be on the machine. The README lists tmux as a requirement and the GitHub CLI as optional, for pull request operations. Then you run agtx from inside a git repository, which is the only documented way to start it.

cd your-project && agtx

The first thing to do on the board is create a task with `o`, then open it with the return key to view the agent session. Movement through the workflow is on `m` for forward, `r` for resume or move back, and `p` for the next phase in cyclic plugins. The `void` plugin is the documented choice when you want a plain session manager: the README's note says it gives full human-in-the-loop control with no spec-driven skill execution and no orchestration on advancing tasks.

The mobile board and the permissions it exposes

Pressing `W` shows a QR code for an installable web app with the board, task details, diffs and the agent's live terminal, including a keyboard, so a permission prompt can be answered away from the desk. The README says this works over your wifi or from anywhere via your tailnet. The Cargo.toml comment is more candid than the README about why this is a compile-time feature rather than always-on: the serve feature is optional "for blast radius", because it serves a board that can start agents running with `--dangerously-skip-permissions`. That is a deliberate trade-off and a reasonable one, but it is also the sharpest edge in the project. A web board that can launch agents with permission checks skipped is only as safe as the network it is reachable on. The README's own framing, over wifi or a tailnet, points at the intended deployment. Anyone exposing that port more broadly is making a decision the project did not make for them.

Where agtx is the wrong tool

Three cases stand out. First, no tmux means no agtx; the requirement is not optional and there is no documented fallback. Second, if you want a graphical environment with inline diffs and click-through review, this is a TUI with Vim keybindings, and the README leans into that rather than apologising for it. Third, and less obvious, the README does not document rollback. The update path is described in detail: a daily GitHub check, a `⬆ 0.2.8 [u]` marker in the header, and `agtx update` to "download, verify and replace this binary in place". Verification is mentioned without saying what is verified or against what, and there is no documented way to return to the previous binary if a new release misbehaves. Task state is local SQLite under `.agtx/`, which you can back up yourself, but the README is silent on migration between versions. If you need a documented downgrade path before adopting a tool, that silence is the answer. The experimental orchestrator carries the same caveat: an agent that autonomously advances phases and checks merge conflicts is a second system acting on your board, and the README marks it experimental rather than stable.

How agtx differs from a plain tmux session manager

The obvious alternative is not another agent product, it is tmux itself plus a few shell aliases. That comparison is fair because agtx is built on tmux and does not hide it. A hand-rolled setup gives you windows and panes, and you decide everything: which agent runs where, when a task is done, what happens next. Nothing is stored, nothing is scheduled, and nothing advances on its own. agtx adds the parts that are tedious to write yourself: a persistent task record in SQLite, git worktrees per task so parallel agents do not fight over the same checkout, a phase model where a different agent can pick up the same task, and an MCP surface that lets an agent manipulate the board. The cost is the inverse: your workflow now lives inside agtx's phase model and its plugin configuration, and the README's plugin list (GSD, Spec-kit, OpenSpec, BMAD, Superpowers) shows how much of the behaviour comes from that layer rather than the binary. If you only ever run one agent on one task at a time, the board is overhead and tmux alone is the better answer.

Licence, maintenance and what an upgrade costs you

The repository states Apache-2.0 in its README badge and in the metadata supplied with the project, while Cargo.toml declares `license = "MIT"` for the package. Those two do not agree, and anyone who needs certainty about the terms should read the LICENSE file at the repository root rather than either declaration. This is a factual discrepancy, not a legal opinion, and it is the kind of thing worth resolving before the project is embedded in a distributed product. On maintenance, the last push was on 2026-09-10, and the release history shows v1.0.3 on 2026-08-31, v1.0.4 on 2026-09-01 and v1.0.5 on 2026-09-07. The repository is not archived. Upgrade cost is low in the ordinary case: agtx checks GitHub once a day and `agtx update --check` reports whether a newer release exists and exits 1 when one does, which is usable from a script. The binary replaces itself in place. What is not documented is what happens to `.agtx/` task data across versions, so a backup of that directory before an update is the prudent move, and the README does not say so.

Editorial conclusion

Adopt agtx if you already run coding agents from a terminal and want one board, per-task git worktrees and automatic agent switching between phases, and you are willing to keep tmux and a working git repository in the loop. Skip it if you want a graphical IDE, if you have no tmux on the machine, or if you need a documented rollback path before you let it rewrite task state. Verify first that the plugin whose workflow you intend to use is the one you actually want, because the README's note says the void plugin is the choice when you want a plain session manager with full human-in-the-loop control and no spec-driven skill execution.

Frequently asked questions

Official sources

1. fynnfluegge/agtx on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases