Issue Trackers Built for AI Coding Agents, Compared

Search "beads vs task master" and you get a Reddit thread, two READMEs, and a generic "best MCP servers" listicle that puts Linear and Todoist next to tools built for a completely different job. That is not a fair comparison. An AI coding agent writing its own tickets during a live session needs different things from a human clicking through a board once a day, and seven tools now build for that specifically: Beads, Task Master, Backlog.md, Vibe Kanban, CCPM, Hiveship, and Trail. This post scores all seven, including Trail, on the same four axes, then names what every one of them still gets wrong.

What makes a tracker agent-native: a four-part test

A tool earns the label "agent-native" if it answers four questions the same way an agent needs answered, not the way a human project manager would ask them:

• Where does the data live? Committed alongside the code as files, in a local database the agent's process owns, or on a server neither the agent nor the repo controls.
• Does anything survive between sessions besides the task list? A closed task is not the same as a lesson learned. Does the tool carry forward gotchas, decisions, or commands that no single task captures?
• Is authorship recorded? When a card changes, does the tool know whether a human or the agent made that specific edit, or does every change look the same in the log?
• Who besides the developer can see it? A teammate, a client, a compliance reviewer. Most of these tools answer "nobody, unless they can read a terminal or a git diff."

Score each tool honestly against those four and the category splits cleanly into git-native local tools and hosted ones, with very different tradeoffs on each side.

Beads: git-backed database, CLI only, built for the agent to write

Beads is Steve Yegge's issue tracker for coding agents, released in October 2025 and, by Yegge's own account, adopted fast enough to draw a thousand GitHub stars in under a week. The bd CLI stores issues in an embedded Dolt database (a version-controlled SQL engine) under .beads/, with a running export to .beads/issues.jsonl for anyone who wants to read the queue as plain text or review it in a pull request. Every issue gets a short hash-based ID like bd-a3f8, specifically so two agents working in parallel branches don't collide on sequential numbers, and issues link to each other with relates-to, duplicates, supersedes, and blocks edges, giving the agent a real dependency graph instead of a flat list. A bd admin compact command summarizes old closed issues, either through an agent-driven review pass or, in a legacy mode, an LLM call, so the context an agent has to reread doesn't grow forever.

Beads is MIT-licensed, CLI-only with no web interface, and everything lives in files under the project's own git history. That is also its constraint: nothing in Beads is shared across projects, and nothing survives outside a task's own record. A commit convention or a deploy gotcha that isn't tied to one specific issue has nowhere to go.

Task Master: one PRD becomes one tasks.json, and stays that way

Task Master takes the opposite shape. Point it at a product requirements document and its task-master parse-prd command turns that PRD into a structured tasks.json file under a .taskmaster/ directory, one file per project, with dependencies, priorities, and test strategies attached to each task. From there, task-master list and task-master next are how an agent or a developer works the queue, and task-master analyze-complexity can flag tasks worth breaking down further. It runs as an MCP server, so Claude Code, Cursor, Windsurf, and several other editors and CLIs can call it directly rather than shelling out.

The license is MIT with a Commons Clause attached, which is worth reading closely: you can use, modify, and ship products built with Task Master, but you cannot sell Task Master itself or offer it as a hosted service. Structurally, tasks.json is a snapshot of one PRD's plan. Nothing about the format expects new, unplanned work to keep landing in it the way an issue tracker does, and there is no notion of authorship beyond whatever git blame tells you about the file.

Backlog.md: markdown files in the repo, kanban in the terminal and the browser

Backlog.md stores every task as a separate markdown file inside a backlog/ folder in the repository, with a configurable ID prefix per project. That single design choice is the whole pitch: tasks are reviewable in a pull request exactly like code, and git log on the backlog folder is the task's authorship history for free, no separate audit feature required. The CLI renders a terminal kanban board with backlog board, and a bundled local web UI (backlog browser) gives the same data a drag-and-drop view. It explicitly supports Claude Code, Gemini CLI, Codex, and any other MCP or CLI-compatible agent, and enforces a three-checkpoint workflow: review the task spec before coding starts, review the implementation plan before code is written, and review the code itself in a single-task pull request.

Backlog.md is MIT-licensed and free, with git integration optional (backlog init --no-git works too). Like Beads, its ceiling is the repo boundary: nothing here is shared across projects, and there's no notion of memory beyond the tasks themselves.

Vibe Kanban: parallel agent orchestration, now community-run

Vibe Kanban is less a tracker than an orchestration layer for running several agents at once: it manages the git worktrees, kicks off setup scripts per agent, and moves a task's status automatically when an agent starts work or opens a pull request, across Claude Code, Codex, Gemini CLI, Cursor, and several others. It runs locally with npx vibe-kanban, and its board state lived on a hosted service for teams that wanted one.

That hosted layer is going away. Bloop, the company behind Vibe Kanban, announced on April 10, 2026 that it was shutting down, writing that "the vast majority are free users and we couldn't find a business model that we could get excited about." Vibe Kanban itself isn't dying: it continues as an open-source, community-maintained project, with remote features staying up for 30 days past the announcement (plus a data export tool) before the product moves to a fully local architecture. If you were relying on Vibe Kanban's hosted board for anything a non-technical teammate needed to see, that option is gone; the orchestration and the local kanban view are not.

CCPM: GitHub Issues plus worktrees, and which fork is the real one

CCPM turns a spec into GitHub Issues and gives each parallel agent its own git worktree to work in, so multiple Claude Code instances can run against the same epic without stepping on each other's branches. Locally, everything lives under .claude/: PRDs, epics, and per-task update files, with git commits formatted as Issue #N: description and progress posted back as issue comments so a human can watch an agent work without opening a terminal. GitHub sync is explicit and optional, not a hard requirement, but the tool is built around the assumption that GitHub Issues is the shared source of truth once you turn it on.

CCPM is MIT-licensed and has been forked heavily, including into agent-specific ports that adapt the same worktree-and-issues workflow for coding agents other than Claude Code. That's useful if you're not on Claude Code, but it means "CCPM" isn't one artifact: which fork has the fix or the feature you want depends on which one someone happened to port it into, and there's no canonical place that tracks which forks are current.

Hiveship: hosted, live agent streaming, PR linking, internal teams only

Hiveship is a hosted board built specifically to delegate work to Claude Code, Cursor, or Codex and watch it happen: agent runs stream live over server-sent events, so status changes and tool calls show up the moment they happen rather than after the fact. When an agent's work lands as a pull request, Hiveship links it automatically, so a finished issue in the review queue comes with a direct link to the PR diff on GitHub, no manual cross-referencing required. Pricing starts free (2 projects, 100 issues, 1 agent) and runs to a $19-a-month Pro tier and a $59-a-month Team tier with unlimited agents and runs.

Hiveship is positioned for internal engineering teams running their own agents, not for showing progress to an outside client, and it's hosted-only with no self-hosting or open-source option. Its live streaming and automatic PR linking are ahead of anything else on this list, including Trail, which records what happened after the fact rather than watching it live.

Trail: hosted, MCP-based, and the only one with memory that outlives a task

Every tool above ties its record to the task: close the issue, and whatever the agent learned while working it is gone unless someone happened to write it into that issue's body. Trail is built around a second store next to the board: project reference memory, durable per-project notes on gotchas, decisions, and deploy steps that the next session reads back automatically when it opens that project folder, shared across every person and every agent working on it, not filed under any single card. It connects over MCP as the usetrail npm package, and each folder maps to one project with no per-project setup, so a person can have several client projects open side by side without cross-contaminating instructions.

Trail is a hosted product, not a git-native one: your issues live in Trail's database, not in files you commit, which is the wrong shape if your hard requirement is that everything stays inside the repo. The free plan covers 3 projects and 3 people with unlimited AI agents; a $19-a-month Team plan adds a read-only client portal and PDF delivery reports at 10 projects, and a $49-a-month Studio plan removes the project and people caps.

The full comparison table

Updated 3 September 2026. The authorship column changed for one row since this was first published: on 5 August 2026 Trail started stamping every card with whether a human or an agent created and changed it, and keeping the full change history per card. That is now the only entry in this table where the human-versus-agent split is recorded as a field rather than inferred from git. Nothing else in the comparison has changed.

What every option on this list is still missing

Line the seven up and the gaps repeat more than the strengths do:

• The default is free and open source, and hosted tools are the exception. Beads, Task Master, Backlog.md, CCPM, and Vibe Kanban's local mode cost nothing and keep data in files you already control. That baseline is real competition, not a footnote, for anyone whose requirement is that issues live in git.
• Nothing here links a task to its pull request automatically except Hiveship. Trail and the rest record what happened after someone reports it or after a session ends; Hiveship watches the agent work and connects the dots live. If your team wants that specific mechanic, nothing else on this list matches it yet.
• Cross-session memory that isn't tied to one task is rare. Five of the seven tools here only remember what's written inside an open or closed issue. Trail is the one exception with a separate project memory store, but even Trail's memory lives on Trail's servers, not in the repo.
• A client-facing, read-only view barely exists. Hiveship explicitly does not offer one. Trail does, on paid plans only. Everyone else assumes the only audience is people who can already read a terminal or a GitHub repo.

How to choose in ten minutes, by team shape

If your actual blocker is that a hand-maintained plan file keeps losing state between sessions, start with why todo.md stops working past the third Claude Code session before picking a tool off this list. And if Beads specifically is what you're weighing against a hosted option, the tradeoffs go deeper than this table: see where Beads' local-first design runs out of road.