🏄🏼‍♂️ agtx

The terminal-native agentic development environment for 10x productivity.

A blackboard for coding agents - One shared board. A fleet of agents. 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, e.g. Codex planning, Claude implementing, Grok review.

Quick Start • Features • Usage • Mobile • Skills • MCP Server • Plugins • Orchestrator • Configuration • Benchmark

---

Features

• Supported Agents:  Claude Code Codex Grok Cursor OpenCode Antigravity Gemini CLI Copilot pi
• Parallel Multi-agent task lifecycle: Configure different agents per workflow phase — e.g. Grok for research, Claude for implementation, Codex for review — with automatic agent switching and context handover.
• Multi-project Kanban board: Manage agent sessions across all projects via a single TUI without leaving your terminal.
• Vim-native Keybindings: Control the board and agent sessions with your Vim-powered muscle memory.
• Mobile support: Press W and scan the QR for an installable web app with the board, task details, diffs and the agent's live terminal — including a keyboard, so you can answer a permission prompt without going back to your desk. Over your wifi, or from anywhere via your tailnet. See Mobile.
• Orchestrator agent (experimental): A dedicated agent that autonomously manages your kanban board via MCP — delegates to coding agents, advances phases, checks for merge conflicts.
• Brainstorm & Sweep skills: Capture ideas and push them to the board from any coding agent session — /agtx:brainstorm to explore freely, /agtx:sweep to decompose and create tasks with one confirmation step.
• Spec-driven plugins: Plug in GSD, Spec-kit, OpenSpec, BMAD, Superpowers and more — fully customizable. Ddefine your own workflow via a single TOML file. See Plugins how to create a plugin.

[!NOTE] 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?

Choose the void plugin and enjoy agtx as a batteries included multi-agent session-manager.

Quick Start

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

# Run in any git repository
cd your-project && agtx

[!NOTE] Add .agtx/ to your project's .gitignore to avoid committing worktrees and local task data.

# Install from source — `serve` adds the mobile board (`W`), and the
# published binaries are built with it
cargo build --release --features serve
cp target/release/agtx ~/.local/bin/

Updating

agtx checks GitHub once a day for a newer release and shows ⬆ 0.2.8 [u] in the board header when there is one. Press u for the details and one key to install it, or from a shell:

agtx update          # download, verify and replace this binary in place
agtx update --check  # report only; exits 1 when an update is available
agtx --version

Requirements

• tmux — agent sessions run in a dedicated tmux server
• gh (optional) — GitHub CLI for PR operations

Usage

Why agtx? - The blackboard model

Most AI coding tools give you one agent, one task, one terminal. agtx is built on a different and much older idea: the blackboard system.

A blackboard system is an approach where a common knowledge base — the blackboard — is iteratively updated by a diverse group of specialist knowledge sources, starting from a problem specification and ending with a solution. Each specialist writes a partial solution to the blackboard when the state on the board matches what it can contribute.

— after Blackboard system, Wikipedia (CC BY-SA)

That architecture was designed for problems that are too ill-defined for a single solver and too interdependent to split cleanly up front. Shipping software with coding agents is exactly that problem, so agtx implements the model directly:

The dependency graph gives the blackboard its structure. Tasks references they build on, forming a graph of partial solutions - agtx holds downstream tasks until their dependencies reach Review or Done, then carries the relevant diffs and artifacts into the dependent task's context.

        ┌───────────────────────────────────────────────────────────┐
        │  CONTROL     orchestrator agent · phase gates · dep graph │
        └─────────────────────────────┬─────────────────────────────┘
                                      │
        ┌─────────────────────────────▼─────────────────────────────┐
        │                       THE BLACKBOARD                      │
        │     backlog  →  planning  →  running  →  review  →  done  │
        │   dependency graph · specs · plans · diffs · reviews      │
        └────▲─────────▲─────────▲─────────▲─────────▲─────────▲────┘
             │         │         │         │         │         │
        ┌────┴───┐ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐
        │ Claude │ │ Codex │ │Gemini │ │Cursor │ │ Grok  │ │  ...  │
        └────────┘ └───────┘ └───────┘ └───────┘ └───────┘ └───────┘
           KNOWLEDGE SOURCES — one git worktree + tmux window each

Mobile

Press W on the board to serve it to your phone. agtx prints a QR code; scanning it pairs the device and opens an installable web app with the board, task details, git diffs, and the agent's live terminal — including a keyboard, so you can answer a permission prompt from wherever you are.

# Or start it yourself, without the TUI
agtx serve                       # this machine only
agtx serve --tunnel              # your tailnet — anywhere, your devices only
agtx serve --devices             # list paired devices
agtx serve --revoke <id>         # revoke one; --revoke-all for the lot

Two keys in the overlay, each a whole action: s serves to the local network, t serves via your tailnet.

[!IMPORTANT] agtx never opens a port on its own. Serving lasts for as long as that agtx runs: quit it and the server stops, so the next time you want the board on your phone you press W then s/t again. Pairing does not change this — it is a credential, not a trigger, and a paired phone whose Mac is not serving just times out.

[!NOTE] This needs a binary built with --features serve. The released ones are; a local cargo build --release without it reports "this build has no web server" under both options.

[!IMPORTANT] Anything that can reach this server can read every task, every diff and every agent's screen, and can type into a running agent — which is arbitrary code execution on your machine. So: loopback needs no credential because reaching it already means being on the machine, and everything wider requires a paired device. Tokens are per-device and stored hashed, so a lost phone is revoked without disturbing the rest. --tunnel public publishes to the open internet and is deliberately not offered behind a keypress.

Actions queue; they do not execute on their own. Moving a task writes a request that only a running agtx picks up, so with no TUI open your taps are accepted and then wait — the board says so rather than pretending. Creating, editing and deleting Backlog tasks take effect immediately, since they need no agent. Starting the server with W keeps the two together by construction.

Brainstorm & Sweep Skills

Two companion skills for capturing ideas in any coding agent session and turning them into tasks in the agtx board.

Typical flow:

/agtx:brainstorm   ← explore the idea freely
      ↓
/agtx:sweep        ← extract tasks, confirm, push to board
      ↓
agtx board         ← tasks appear in Backlog, ready to advance

The brainstorm skill keeps the agent in discussion mode — asking questions, surfacing trade-offs, no code or plans. When the conversation feels complete, run /agtx:sweep to decompose outcomes into feature-level tasks and push them to the board with a single confirmation step.

Install

claude plugin marketplace add fynnfluegge/agtx
claude plugin install agtx@agtx-marketplace
claude mcp add --scope user agtx -- agtx mcp-serve

codex mcp add agtx -- agtx mcp-serve

{
  "name": "local-repo",
  "plugins": [
    {
      "name": "agtx",
      "source": {
        "source": "local",
        "path": "./plugins/agtx"
      },
      "policy": {
        "installation": "AVAILABLE",
        "authentication": "ON_INSTALL"
      },
      "category": "Productivity"
    }
  ]
}

gemini mcp add agtx -- agtx mcp-serve
echo "@skills/sweep/SKILL.md" >> ~/GEMINI.md

cursor mcp add agtx -- agtx mcp-serve
cp skills/sweep/SKILL.md ~/.cursor/rules/agtx-sweep.md

grok mcp add agtx -- agtx mcp-serve
mkdir -p ~/.grok/skills/agtx-sweep && cp skills/sweep/SKILL.md ~/.grok/skills/agtx-sweep/SKILL.md

agy mcp add agtx agtx mcp-serve
mkdir -p ~/.gemini/antigravity-cli/skills/agtx-sweep
cp skills/sweep/SKILL.md ~/.gemini/antigravity-cli/skills/agtx-sweep/SKILL.md

mkdir -p ~/.pi/skills/agtx-sweep && cp skills/sweep/SKILL.md ~/.pi/skills/agtx-sweep/SKILL.md

[!NOTE] The project must have been opened in agtx at least once to appear in list_projects. Run agtx in your project directory first.

Configuration

Config file location: ~/.config/agtx/config.toml

General

default_agent = "claude"
fullscreen_on_enter = false  # When true, Enter opens the tmux pane fullscreen inside agtx
agent_hooks = true           # Let agents report their own phase status via lifecycle hooks
auto_trust = false           # Answer agents' trust prompts on your behalf
update_check = true          # Check GitHub daily for a new release (see Updating)

Worktree Base Branch

agtx creates a new git worktree for each task. By default it auto-detects the base branch in this order: main, then master, then the current branch. You can override this to force a specific base branch (for example dev or develop).

Global worktree defaults can be set here:

# ~/.config/agtx/config.toml
[worktree]
base_branch = "dev"
worktree_dir = ".worktrees"  # default: ".agtx/worktrees"

worktree_dir is the directory (relative to project root) where task worktrees are created. Defaults to .agtx/worktrees if not set.

Project Configuration

Per-project settings can be placed in .agtx/config.toml at the project root:

# Base branch used when creating new task worktrees (optional)
base_branch = "dev"

# Directory where worktrees are created (optional, default: ".agtx/worktrees")
worktree_dir = ".worktrees"

# Files to copy from project root into each new worktree (comma-separated)
# Paths are relative and preserve directory structure
copy_files = ".env, .env.local, web/.env.local"

# Shell command to run inside the worktree after creation and file copying
init_script = "scripts/init_worktree.sh"

# Shell command to run inside the worktree before removal
cleanup_script = "scripts/cleanup_worktree.sh"

base_branch controls which branch new task worktrees are created from. If omitted or empty, agtx auto-detects main, master, or falls back to the current branch.

Per-Phase Agent Configuration

By default, all phases use default_agent. You can override the agent for specific phases globally or per project:

# ~/.config/agtx/config.toml
default_agent = "claude"

[agents]
research = "gemini"
planning = "claude"
running = "claude"
review = "codex"

# .agtx/config.toml (project override — takes precedence over global)
[agents]
running = "codex"

Plugins

Plug any spec-driven framework into the task lifecycle. Define commands, prompts, and artifacts — agtx handles phase gating, artifact polling, worktree sync, agent switching, and autonomous execution.

Press P to switch plugins. Ships with 10 built-in:

Agent Compatibility

Commands are written once in canonical format and automatically translated per agent:

✅ Skills, commands, and prompts fully supported · 🟡 Prompt only, no interactive skill support · ❌ Not supported

name = "my-plugin"
description = "My custom workflow"

[commands]
research = "/my-plugin:research {task}"
planning = "/my-plugin:plan"
running = "/my-plugin:execute"
review = "/my-plugin:review"

[prompts]
planning = "Task: {task}"

name = "my-plugin"
description = "My custom workflow"

# Shell command to run in the worktree after creation, before the agent starts.
# {agent} is replaced with the agent name (claude, codex, gemini, etc.)
init_script = "npm install --prefix .my-plugin --{agent}"

# Restrict to specific agents (empty or omitted = all agents supported)
supported_agents = ["claude", "codex", "gemini", "opencode"]

# Extra directories to copy from project root into each worktree.
# Agent config dirs (.claude, .gemini, .codex, .github/agents, .config/opencode)
# are always copied automatically.
copy_dirs = [".my-plugin"]

# Individual files to copy from project root into each worktree.
# Merged with project-level copy_files from .agtx/config.toml.
copy_files = ["PROJECT.md", "REQUIREMENTS.md"]

# When true, enables Review → Planning transition via the `p` key.
# Each cycle increments the phase counter ({phase} placeholder).
# Use this for multi-milestone workflows (e.g. plan → execute → review → next milestone).
cyclic = false

# Artifact files that signal phase completion.
# When detected, the task shows a checkmark instead of the spinner.
# Supports * wildcard for one directory level (e.g. "specs/*/plan.md").
# Use {phase} for cycle-aware paths (replaced with the current cycle number).
# Omitted phases show no completion indicator.
[artifacts]
research = ".my-plugin/research.md"
planning = ".my-plugin/{phase}/plan.md"
running = ".my-plugin/{phase}/summary.md"
review = ".my-plugin/{phase}/review.md"

# Slash commands sent to the agent via tmux for each phase.
# Written in canonical format (Claude/Gemini style): /namespace:command
# Automatically transformed per agent:
#   Claude/Gemini: /my-plugin:plan (unchanged)
#   OpenCode:      /my-plugin-plan (colon -> hyphen)
#   Codex:         $my-plugin-plan (slash -> dollar, colon -> hyphen)
#   Cursor/Grok/Antigravity: /my-plugin-plan (colon -> hyphen)
# Omitted phases fall back to agent-native agtx skill invocation
# (e.g. /agtx:plan for Claude, $agtx-plan for Codex).
# Set to "" to skip sending a command for that phase.
# Use {phase} for cycle-aware commands (replaced with the current cycle number).
# Use {task} to inline the task description.
[commands]
preresearch = "/my-plugin:research {task}"  # Used only when no research artifacts exist yet
research = "/my-plugin:discuss {phase}"
planning = "/my-plugin:plan {phase}"
running = "/my-plugin:execute {phase}"
review = "/my-plugin:review {phase}"

# Prompt templates sent as task content after the command.
# {task} = task title + description, {task_id} = unique task ID, {phase} = cycle number.
# Omitted phases send no prompt (the skill/command handles instructions).
[prompts]
research = "Task: {task}"

# Text patterns to wait for in the tmux pane before sending the prompt.
# Useful when a command triggers an interactive prompt that must appear first.
# Polls every 500ms, times out after 5 minutes.
[prompt_triggers]
research = "What do you want to build?"

# Files/dirs to copy from worktree back to project root after a phase completes.
# Triggered automatically when the phase artifact is detected (spinner → checkmark).
# Useful for sharing research artifacts (specs, plans) across worktrees.
[copy_back]
research = ["PROJECT.md", "REQUIREMENTS.md", ".my-plugin"]

# Auto-dismiss interactive prompts that appear before the prompt trigger.
# Each rule fires when ALL detect patterns are present and the pane is stable.
# Response is newline-separated keystrokes (e.g. "2\nEnter" sends "2" then Enter).
[[auto_dismiss]]
detect = ["Map codebase", "Skip mapping", "Enter to select"]
response = "2\nEnter"

.agtx/plugins/my-plugin/
├── plugin.toml
└── skills/
    ├── agtx-plan/SKILL.md
    ├── agtx-execute/SKILL.md
    └── agtx-review/SKILL.md

How It Works

Architecture

┌─────────────────────────────────────────────────────────┐
│                      agtx TUI                           │
├─────────────────────────────────────────────────────────┤
│  Backlog  │  Planning  │  Running  │  Review  │  Done   │
│  ┌─────┐  │  ┌─────┐   │  ┌─────┐  │  ┌─────┐ │         │
│  │Task1│  │  │Task2│   │  │Task3│  │  │Task4│ │         │
│  └─────┘  │  └─────┘   │  └─────┘  │  └─────┘ │         │
└─────────────────────────────────────────────────────────┘
                    │           │
                    ▼           ▼
┌─────────────────────────────────────────────────────────┐
│                 tmux server "agtx"                      │
│  ┌────────────────────────────────────────────────────┐ │
│  │ Session: "my-project"                              │ │
│  │  ┌────────┐  ┌────────┐  ┌────────┐                │ │
│  │  │Window: │  │Window: │  │Window: │                │ │
│  │  │task2   │  │task3   │  │task4   │                │ │
│  │  │(Claude)│  │(Claude)│  │(Claude)│                │ │
│  │  └────────┘  └────────┘  └────────┘                │ │
│  └────────────────────────────────────────────────────┘ │
│  ┌────────────────────────────────────────────────────┐ │
│  │ Session: "other-project"                           │ │
│  │  ┌───────────────────┐                             │ │
│  │  │ Window:           │                             │ │
│  │  │ some_other_task   │                             │ │
│  │  └───────────────────┘                             │ │
│  └────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────┘
                    │           │
                    ▼           ▼
            ┌───────────────────────────┐
            │   Git Worktrees           │
            │  .agtx/worktrees/task2/   │
            │  .agtx/worktrees/task3/   │
            │  .agtx/worktrees/task4/   │
            └───────────────────────────┘

Tmux Structure

• Server: All sessions run on a dedicated tmux server named agtx
• Sessions: Each project gets its own tmux session (named after the project)
• Windows: Each task gets its own window within the project's session

# List all sessions
tmux -L agtx list-sessions

# List all windows across sessions
tmux -L agtx list-windows -a

# Attach to the agtx server
tmux -L agtx attach

Data Storage

• Database: ~/Library/Application Support/agtx/ (macOS) or ~/.config/agtx/ (Linux)
• Config: ~/.config/agtx/config.toml
• Worktrees: .agtx/worktrees/ in each project
• Tmux: Dedicated server agtx with per-project sessions

Docker Sandbox

Run agtx in an isolated Docker container so agents can only touch the project you pass in — no access to the rest of your home directory, credentials are read-only, and any files the agent creates in the project are owned by your host user.

# Run agtx on a project
./docker/sandbox.sh path/to/your-project

# Or from inside the project directory
./docker/sandbox.sh

The sandbox:

• Mounts only the target project as writable; everything else on the host is inaccessible
• Copies ~/.claude credentials read-only at startup so they are never written back to the host
• Runs as a non-root user whose UID/GID matches your host user (files created inside the container appear correctly owned on the host)
• Stores agtx state in named Docker volumes (persists across runs, isolated from your host's agtx data)
• Pre-accepts the bypass permissions prompt, which is appropriate in an isolated container

[!NOTE] Requires Docker Engine (Linux) or Docker Desktop (macOS/Windows). The image is built automatically on first run and cached for subsequent runs.

MCP Server

The agtx MCP server (agtx mcp-serve) exposes the board to any coding agent session via the Model Context Protocol. Used by the orchestrator agent and the brainstorm & sweep skills.

Modes

In global mode all tools require a project_id parameter. Call list_projects first to resolve it.

Tools

Orchestrator Agent (Experimental)

Press O and walk away. Come back to changes ready to merge.

The orchestrator is an AI agent that drives other AI agents to completion. You triage tasks into Planning or Running — the orchestrator takes over from there, advancing each task through its phases until it lands in Review, ready for you to merge.

agtx --experimental   # then press O

What it does:

• Monitors tasks in Planning and Running
• Advances tasks automatically as phases complete (Planning → Running → Review)
• Respects plugin phase rules — checks allowed_actions before each transition
• Detects stuck tasks (idle for 1+ minute without a phase artifact) and reads the agent pane to diagnose the cause
• Nudges stuck agents, answers CLI prompts automatically, or escalates to you with a reason when human input is needed

You triage. It executes. Move tasks from Backlog into Planning or Running — the orchestrator handles the rest. Merging is your call.

MCP Integration

The orchestrator communicates with agtx through the Model Context Protocol (MCP). agtx ships with a built-in MCP server (agtx serve) that exposes the kanban board as a set of tools over JSON-RPC via stdio.

┌─────────────-┐     MCP (stdio)     ┌──────────────┐     SQLite     ┌─────┐
│ Orchestrator │ ←─────────────────→ │  MCP Server  │ ←────────────→ │ DB  │
│ (Claude Code)│                     │ (agtx serve) │                └──┬──┘
└──────┬───────┘                     └──────────────┘                   │
       │  push-when-idle notifications                                  │
┌──────┴───────┐                                                        │
│   TUI (agtx) │ ←───────────────────────────────────────────────────--─┘
└──────────────┘

How it works:

1. When you press O, the TUI registers the MCP server with the orchestrator agent via claude mcp add-json --scope local
2. The orchestrator receives phase completion notifications pushed to its tmux pane when idle
3. It reacts by calling get_task to check allowed_actions, then move_task to advance the task
4. The TUI processes the transition request, executes all side effects (agent switching, skill deployment, prompt sending), and updates the database
5. If a task has been idle for 1+ minute without a phase artifact, the orchestrator is notified — it reads the pane with read_pane_content, then either nudges the agent with send_to_task or calls move_task with escalate_to_user to flag it for your attention
6. Escalated tasks show a ⚠ badge on the kanban board; opening the task popup shows the reason and dismisses the flag
7. MCP registration is cleaned up when the orchestrator is stopped

Benchmark

agtx includes a SWE-bench Lite benchmark runner that uses agtx itself as the agent orchestration layer — driving coding agent workflows against 300 real GitHub bug-fix tasks via the MCP server.

See benchmark/README.md for setup, usage, bundled configs, and evaluation instructions.

Contributing

Contributions are welcome! Whether it's a bug fix, new plugin, agent integration, or documentation improvement.

See CONTRIBUTING.md for the full guide. Here's the short version:

# Fork & clone
git clone https://github.com/<you>/agtx && cd agtx

# Build & test
cargo build && cargo test --features test-mocks

Good First Contributions

Not sure where to start? Here are some ideas:

• Write a plugin — A single plugin.toml is all you need. See Creating a Plugin for the full reference
• Add a new agent — Integrate your favorite AI coding CLI. See the architecture docs for how agents are structured
• Improve documentation — Found something unclear? Help others by improving it
• Report bugs — Open an issue. Reproduction steps are always appreciated
• Browse open issues — Check the good first issue label for beginner-friendly tasks

Development

See CLAUDE.md for full architecture docs and development patterns.

# Build
cargo build

# Run tests (includes mock-based tests)
cargo test --features test-mocks

# Build release
cargo build --release