agtx: a tmux-backed blackboard for running several coding agents on one task
🏄🏼♂️ The blackboard for coding agents - agentic development environment for claude code, codex, cursor, opencode, grok and more.
At a glance
- What is it?
- agtx is a Rust terminal UI that puts a Kanban board in front of Claude Code, Codex, Cursor, Grok, OpenCode and other CLI agents, with per-phase agent switching and an optional MCP orchestrator. It is a session manager first and a workflow engine second, and the difference matters when you pick a plugin.
- Who is it for?
- Adopt agtx if you already run two or more CLI coding agents and want them sharing one task board with explicit phase handovers, and if tmux is already part of how you work. Skip it if you want a single agent with a graphical diff view, or if you expect the Kanban board to enforce correctness rather than just sequence work.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem agtx targets: agent sessions that do not know about each other
Running one coding agent in a terminal is a solved habit. Running three is not. Each CLI keeps its own session state, its own working directory assumptions, and its own idea of what the task is. If you want Codex to plan a change and Claude to implement it, the handover is manual: you copy context between terminals and hope nothing was lost in the copy. agtx is built for that gap. The README describes it as "a blackboard for coding agents" where you "add tasks, delegate to multiple coding agents running in parallel and let different models collaborate on the same task with automatic session switching and context awareness." The intended user is someone already comfortable with several agent CLIs and with tmux, not someone looking for their first coding assistant. The supported list in the README covers Claude Code, Codex, Grok, Cursor, OpenCode, Antigravity, Gemini CLI, Copilot and pi, and the project is written in Rust with an Apache-2.0 licence.
What the board actually coordinates: phases, worktrees and a shared task record
The mechanism visible in the material is a task lifecycle split into named phases (the keyboard table references Planning, Running and Review) with a different agent assignable to each phase. The README gives the example directly: "Grok for research, Claude for implementation, Codex for review", with "automatic agent switching and context handover" between them. Tasks live in columns, and the keys m, r and p move a task forward, back, or to the next phase. Agent sessions themselves run inside "a dedicated tmux server", which is how agtx can attach you to a live terminal, show a diff, and keep sessions alive while you move around the board. The Quick Start note asks you to add .agtx/ to .gitignore "to avoid committing worktrees and local task data", which tells you two things: agtx creates git worktrees, and its state is directory-local rather than global. The Multi-project Kanban claim means one TUI instance can hold sessions for more than one repository, so the board is the aggregation point rather than the repository.
Install, first run, and the serve feature flag
The documented install is a shell script: curl -fsSL https://raw.githubusercontent.com/fynnfluegge/agtx/main/install.sh | bash. From source, the README gives cargo build --release --features serve followed by copying target/release/agtx into a bin directory, and it notes that "serve adds the mobile board (W), and the published binaries are built with it". That flag is worth reading twice: if you build without it, the mobile feature described under the W key is not in your binary. Running it is a single command from inside a repository: cd your-project && agtx. Requirements are listed as tmux, which is mandatory because sessions run in a dedicated tmux server, and gh, which is optional and used for PR operations. Updates are handled in-band: the README says agtx checks GitHub once a day and shows an indicator in the board header, with u to install, plus agtx update, agtx update --check (which exits 1 when an update exists) and agtx --version from a shell. There is no package-manager path documented here, and no configuration file example is included in the supplied material beyond the mention of a TOML file for defining plugins.
The void plugin is the honest default, and the README says so
The most useful note in the README is the one that narrows the product. It tells readers who "just need a plain coding-agent session-manager with full human-in-the-loop control and no spec-driven skill execution and orchestration on advancing tasks" to "choose the void plugin and enjoy agtx as a batteries included multi-agent session-manager." That is an admission that the interesting part of agtx, the part that advances tasks for you, is plugin-supplied. Plugins named in the README include GSD, Spec-kit, OpenSpec, BMAD and Superpowers, and the project says you can define your own "via a single TOML file". The practical consequence: two people running agtx with different plugins are running materially different tools. One has a manual board with agent terminals attached. The other has a spec-driven pipeline where pressing m triggers skill execution. If you evaluate agtx without pinning the plugin, you are not evaluating a single behaviour. The brainstorm and sweep skills are the other half of this: /agtx:brainstorm explores freely, /agtx:sweep decomposes and creates tasks "with one confirmation step", which is a deliberate brake on full autonomy.
The orchestrator is experimental, and the failure modes follow from that
The README labels the orchestrator agent "experimental" and describes it as "a dedicated agent that autonomously manages your kanban board via MCP", delegating to coding agents, advancing phases and checking for merge conflicts. An agent that moves other agents through phases inherits every ambiguity in the phase definitions. If a task is advanced past Review while a diff is still unread, nothing in the described design stops it. The merge-conflict check is the one concrete safety behaviour mentioned, and it is described as a check, not a resolution. Two further constraints are easy to miss. First, tmux is not optional: on a machine without it, the session model has no floor to stand on. Second, the mobile board is a network surface. The README says you press W and scan a QR code for an installable web app showing the board, task details, diffs and "the agent's live terminal, including a keyboard", reachable "over your wifi, or from anywhere via your tailnet". A live terminal you can type into from a phone is convenient and also an access-control decision, and the material does not describe authentication beyond the network boundary itself.
Where agtx is the wrong tool, and what to use instead
agtx assumes a terminal-first, keyboard-driven workflow. The README leans into this with "Vim-native keybindings" and a key table built on h/l, j/k, o, R and /. If your team reviews code in a browser, expects a visual merge UI, or wants one agent with no phase machinery, the board is overhead. The sharper comparison is with the agent CLIs themselves. Claude Code, Codex and Cursor each ship their own session and permission model, and each can be run directly in a terminal or an editor. agtx does not replace them; it wraps them and adds a shared task record plus cross-agent handover. So the real alternative for a single-agent user is simply running that agent, which costs nothing to install and has no tmux requirement and no .agtx/ directory to gitignore. The alternative for a team that wants specification-driven development without a TUI is adopting one of the spec frameworks agtx lists as plugins (Spec-kit, OpenSpec, BMAD) directly, in the editor or CI, and giving up the parallel-session board. The difference in approach is that agtx coordinates running processes, while those frameworks coordinate documents. If your bottleneck is review and approval rather than session juggling, the document-first route addresses the actual problem.
Maintenance, versioning and licence
The release cadence visible in the material is tight: v1.0.3, v1.0.4 and v1.0.5 landed within roughly a week in late August to early September 2026, with the last push to main on 2026-09-10. Rapid patch releases after a 1.0 line usually mean active bug-fixing, and they also mean the surface you install today may shift under you. The built-in updater mitigates that: agtx update downloads, verifies and replaces the binary in place, and agtx update --check lets you script a check that exits 1 when something newer exists. That is a reasonable story for a tool you install as a single binary. The licence is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant, with the usual obligations around preserving notices and stating changes; the supplied material does not include a NOTICE file or any additional terms, and this is not legal advice. One maintenance detail the README does not cover: what happens to in-flight tmux sessions and .agtx/ task data when the binary is replaced mid-task. Verify that against your own workflow before relying on the updater during a long-running task.
Editorial conclusion
Adopt agtx if you already run two or more CLI coding agents and want them sharing one task board with explicit phase handovers, and if tmux is already part of how you work. Skip it if you want a single agent with a graphical diff view, or if you expect the Kanban board to enforce correctness rather than just sequence work. Before trusting it on a real repository, run agtx in a scratch git repo, confirm the .agtx/ directory is in .gitignore, and check whether the plugin you intend to use (void, GSD, Spec-kit, OpenSpec, BMAD, Superpowers) matches the level of automation you actually want, because the plugin choice changes what the board does when you press m.
Community notes