Best Issue Tracker for Coding Agents (2026): 7 Tools Compared, Two Raced Live

Updated: 2026-11-04.

The best issue tracker for coding agents depends on one question: do humans assign work to agents, or do agents claim it themselves? If a person or an orchestrator hands each issue to one agent, pick the tracker with the best delegation, which today is Linear. If agents pick their own work from a shared queue, the claim must be atomic. In our live race against Linear on 2026-11-02, 20 workers per round over 10 rounds, more than one worker was told "claimed" in 10 of 10 rounds, with 183 silent overwrites. In the same race against Radial on 2026-11-04, exactly one worker was told "claimed" in each of the 10 rounds, the other 190 got a 409, and nothing was overwritten. To choose, run the Assign, Claim, Close test: atomic claim, read and write from a CLI or MCP, and close with evidence.

What we measured and what we read: two trackers, Linear and Radial, were raced live. The no-tracker baseline (TODO.md in git) was run as a scripted race. Radial's hosted MCP tool list was measured live. Everything else comes from vendor docs and pricing pages, each with its date. Every benchmark number below comes from the public benchmarks folder (evidence.json, runs of 2026-11-02, plus the Radial race of 2026-11-04), with its evidence id. The summary table is also published as CSV.

#The Assign, Claim, Close test

Score each tracker on three criteria. Each one is a thing an agent does on every issue.

1. Atomic claim. Two agents reach for the same issue at the same moment. Exactly one must win, and the other must be told it lost. A plain assign is last-write-wins: both agents get a success.
2. Read and write from a CLI or MCP. The agent lists, creates, updates and comments without a human relaying anything: an official CLI with JSON output for agents in a shell, or an MCP server for agents in an MCP client.
3. Close with evidence. The agent closes the issue with proof a human can check: a comment with test output, a linked PR, or an attached file.

If humans assign every issue, criterion 1 matters less, and delegation (who owns the issue, who gets told) matters more.

#Results

Download this table as CSV, with a source and a verified date on every row.

Two of the seven were raced live: Linear and Radial. "Not run" means we have no measurement, not that the tracker failed. Beads documents an atomic claim; we have not raced it.

#What the benchmark measured

The benchmark compares Linear, Jira Cloud, Radial and a no-tracker baseline on nine agent tasks, from creating an issue to resuming after a session ends. Each number carries one label: MEASURED (a command in the folder produced it), DOCUMENTED (a vendor page, or Radial's source at commit 9126321), SIMULATED (a scripted agent: git, shell and HTTP, no model) or ESTIMATE. GitHub Issues, Beads, Plane and YouTrack are not in the benchmark; their cells below are from docs.

#The claim race, live against Linear and Radial

Both races have the same shape: 20 workers per round start at a barrier, 10 rounds, one fresh issue per round, and each worker tries to claim the issue once. Linear has no conditional update, so its race used the claim an agent can actually write: read the issue, and if it still says Todo, call issueUpdate to assign and start it (L-LIVE-RACE). Radial's race called POST /api/v1/issues/{id}/claim once per worker, a conditional update that succeeds only if the issue has no assignee or the caller already holds it, and returns a 409 otherwise (R-LIVE-RACE).

The image is the two raw benchmark files read with jq, rendered on Nov 4, 2026: claim-race-graphql.json (Linear, 2026-11-02) and claim-race-rest.json (Radial, 2026-11-04). The issue keys are from the workspaces each race wrote to. In Linear's race, the lowest "claimed" count in one round was 17 (RAD-15) and the highest was 20 (five rounds).

The two runs differ in method, and the differences matter:

• Identities. All 20 Linear workers used one API key, so every update set the same assignee; each worker wrote its own marker into the issue, and the 183 overwrites are markers another worker replaced. Separate identities add no precondition to issueUpdate, so we expect the same result, but we have not run it. Radial's race used 20 identities because a re-claim by the current holder is an idempotent success: with one key, every worker would get a success, and the race would test nothing.
• What the claim writes. Linear's update assigned the issue and moved it to started. Radial's claim sets only the assignee; it does not move the status.
• A discarded run. On production, an issue created by an agent is auto-assigned to the key's human owner. Our first Radial run did not account for this, so all 200 claims got a 409, and we discarded it. The harness now unassigns each issue and reads it back as unassigned before the round. All test issues were deleted and the keys revoked after the run.

#The no-tracker baseline

The baseline is the setup most agent users start with: a TODO.md in git. Two scripted agents both took "first open task", which is the usual heuristic and the worst case (summary.json).

Git beats a shared checkout here: it rejects the second push, so the collision is visible. It still hands the repair to the agent. The file also grows: an agent that reads TODO.md and DECISIONS.md whole reads 7,325 bytes at 50 decisions, 28,916 at 200, and 144,451 at 1,000 (E-BASE-SCALE-*). Resuming after a session ends re-read 7,217 bytes at 50 tasks (E-BASE-T8-bytes).

One real agent ran the baseline too. Claude Code (Sonnet) picking up the next task from TODO.md took a median 5 turns, 125,740 input tokens (112,459 of them cache reads), 664 output tokens, 11.3 seconds and $0.071, and succeeded 3 of 3 times (E-TOK-BASE-T2-*). n=3 is below the benchmark's own bar of 5.

#MCP payload and a scripted Linear flow

An MCP client loads the server's whole tools/list into the agent's context before the first call. We measured two.

A scripted flow against Linear's MCP server (create, list next, claim and start, proof comment, done, done note) took 6 calls and a median 3,187 ms per flow (min 2,608, max 3,293), about 9.1 KB read back, over 5 trials with no model time (L-LIVE-T1T4). We have no live Radial task run, so there is no Radial latency to compare it to.

#Capability coverage

The benchmark scores 19 things a coding agent does in a tracker against each official surface: yes = 1, partial = 0.5. Three rows (prototype preview, session logs, done-proof) describe features only Radial ships, so the second score drops them.

Read the scores with three caveats. We picked the rows. Radial is scored from its own source, which shows everything it does, while Linear and Jira are scored from docs, which can leave things out. And Linear's low score is mostly unknowns: our Jira vs Linear comparison re-scores those cells from the live tool list. Radial loses or ties on bulk edits in the CLI (Jira's acli has them), webhooks (no Radial surface manages them) and import or export over MCP.

#Feature matrix

"Not documented" means we could not find it on the vendor's pages, not that the feature is missing. Dates: vendor facts and prices verified on Nov 4, 2026, except tool and command counts, rate limits and Jira's credit figures, which are from Nov 2, 2026. Radial from its source and its CLI on main, Nov 4, 2026.

#Claim and close-out

#Agent surfaces: CLI, MCP and API

#Agent identity, permissions and pricing

#Where the data lives: hosting, offline and git

#Linear

Linear is the best of the seven when humans hand work to agents. Delegating an issue to an agent "sets it as the delegate, not the assignee," so the human keeps ownership (Linear agent docs), and agent sessions are built for one agent per issue. The Cursor integration is the clearest example: "Assign any Linear issue to Cursor, and a cloud agent will get to work," and "Once the task is complete, the Cursor agent will update the issue automatically with a PR" (Linear Cursor integration, as of Nov 4, 2026). On the Cursor side, a Cursor admin connects it and usage-based pricing must be on. Linear says "Agents are not counted as billable seats in Linear."

The screenshot is Linear's agent platform docs, captured headless on Nov 4, 2026: the delegate menu sits under the human assignee.

Its MCP server lists 60 tools in a 101,447-byte tools/list, and a read-only endpoint, /mcp/readonly, suits a reviewer agent that should never write. A scripted create, pick up, prove and close flow took 6 MCP calls, a median 3,187 ms over 5 trials.

The gap is the claim. Linear has no conditional update, so an agent that picks its own work reads the issue and then assigns it, and our race shows what happens next: 10 of 10 rounds with more than one claimant. Linear ships no official issue-management CLI; agents in a shell use the GraphQL API or a community CLI. See the Jira vs Linear comparison for the CLI options, rate limits and credits.

#GitHub Issues

GitHub Issues is the closest tracker to the pull requests. An issue and the PR that closes it sit in the same repo, so "close with evidence" is a linked PR, and "Fixes #123" closes the issue on merge. Agents get an official CLI, gh issue with --json, and an official MCP server, github-mcp-server, with an issues toolset. GitHub's own agent works from the same issues: "Copilot cloud agent is available for all paid Copilot plans," and it can start from issues, the GitHub CLI or the GitHub MCP server.

The screenshot is GitHub's Copilot sessions docs, captured headless on Nov 4, 2026.

Issues are on GitHub Free, and GitHub Team is $4 per user per month (pricing, as of Nov 4, 2026). GitHub Apps are not on GitHub's list of billed users, though GitHub does not address agents directly. Copilot cloud agent needs a paid Copilot plan, and assigning an issue to it "always creates a pull request." The limit is the claim: assigning is a plain write, and GitHub documents no conditional claim. Planning views live in GitHub Projects, so the list is flatter than a dedicated tracker.

#Beads

Beads is agent memory inside the repo. Its GitHub description reads "A memory upgrade for your coding agent," and it is MIT-licensed with 28,496 stars (github.com/gastownhall/beads, as of Nov 4, 2026). The CLI is bd, and the claim is documented as atomic: "when multiple agents pull from the same ready queue, the first claim wins." That makes Beads the one tool here besides Radial that documents an atomic claim.

The screenshot is the Beads repo, captured headless on Nov 4, 2026.

Beads stores issues in a Dolt database inside .beads/, and syncs between machines with bd dolt push and bd dolt pull through your git remote. It is offline-first. The default embedded mode is a single writer; a server mode allows many. A beads-mcp server ships in the repo, though its README recommends the CLI wherever the agent has a shell. There is no official review UI (community-built ones exist) and no permission model in its docs. Beads fits one agent, or a few on one machine, that need a structured memory next to the code. We have not raced its claim.

#Jira

Jira is the pick when your company already runs on it and your agents work in a shell. It ships an official CLI, acli, with 46 documented commands, --json on create, edit, search and transition, and bulk edits by JQL. In the benchmark's matrix acli scores 12.0 of 19, the best non-Radial surface.

The screenshot is the acli jira workitem assign reference, captured headless on Nov 4, 2026. Every option is a plain assign; none is conditional.

The Rovo MCP server covers agents in an MCP client, though transitions and attachments take extra round trips through discover and execute* tools, and it scores 7.5 of 19. Jira documents no conditional assign; we have not raced it live. Jira Free covers up to 10 users, Standard is $9.70 per user per month for new purchases, service accounts are not billed (5 free), and a cross-product Rovo search "may consume up to 10 Rovo credits per call" (as of Nov 2, 2026).

#Plane

Plane is the pick if you want to self-host. The Community Edition is AGPL-3.0 with no user limit, and the cloud has an official MCP server at mcp.plane.so; the hosted service "cannot reach private Plane instances," so a self-hosted one runs its own (Plane MCP docs, as of Nov 4, 2026). Plane publishes no CLI for issues, and our sources document no conditional claim.

The screenshot is plane.so/pricing, captured headless on Nov 4, 2026, with cloud and yearly billing selected. Pro is $8 per user per month billed monthly. Installed agents "do not count as billable users" in Plane's agents docs (beta), and Plane's own agents draw from AI credits, none on Free. Self-hosting moves the cost to your server and your time.

#YouTrack

YouTrack serves an MCP server from each instance: "YouTrack exposes its MCP server over the Streamable HTTP transport," at https://<instance-name>.youtrack.cloud/mcp, acting with the permissions of the signed-in account (YouTrack MCP docs, as of Nov 4, 2026). It "doesn't expose an MCP server over stdio."

The screenshot is YouTrack's MCP docs, captured headless on Nov 4, 2026.

We found no official CLI in its docs, and its assign tool is a plain assign. A new Cloud instance is free "for up to 10 users and 3 helpdesk agents"; JetBrains' sales help lists $5.40 per user per month on monthly billing. YouTrack Server, the self-hosted edition, is free up to 10 users. Git integration covers GitHub, GitLab and Bitbucket. YouTrack does not document how an agent with its own account is billed; its user docs say each standard user takes one license.

#Radial

Radial is a hosted issue tracker with a board for humans and a CLI plus an MCP server for agents, over one record. The claim is one conditional write: radial claim ENG-42, claim_issue over MCP, or POST /v1/issues/{id}/claim assigns only if nobody holds the issue. Every other claimant gets a 409 naming the holder, and the CLI exits 3 so the agent takes the next issue.

The image is real output from the radial CLI source on main, run offline on Nov 4, 2026. The last command shows what an agent sees with no credential: a JSON error with the fix in the message (E-RAD-CLI-noauth).

The hosted MCP server lists 45 tools in a 21,020-byte tools/list, measured live. Agents close with radial close ENG-42 -m "Fixed in #412", or record a test the CLI ran itself with radial build gate --exec -- pnpm test, and the result shows on the issue. Key scopes (read, triage, write) limit what an agent key can do.

Pricing: $50 per human user per year, flat. Agents are not billed as seats, nothing is metered, and there is nothing to self-host.

In the live race on production on 2026-11-04, 20 agent keys claimed each of 10 issues at once: exactly one worker per round was told "claimed" and was the final owner, the other 190 got a 409, with 0 silent overwrites and 0 errors (R-LIVE-RACE). That is one run of 10 rounds over the REST endpoint; we did not race radial claim or claim_issue separately.

The limits, plainly:

• No free tier, no trial and no monthly plan.
• No SAML SSO or SCIM.
• No push to agents. Agents poll for new work; no webhook wakes them, and webhooks are managed in the settings UI only.
• No bulk edit in the CLI (MCP and REST have it) and no read-only MCP endpoint, which Linear has.
• Key scopes are workspace-wide, where Jira has per-project permission schemes. A 429 carries no Retry-After yet.

The screenshot is radial.build/developers, captured headless on Nov 4, 2026.

#How to choose

1. Run the race on the tracker you have. Make one scratch issue. Start 20 workers at once; each reads the issue and, if it is still unassigned, assigns it and prints "claimed". If more than one worker prints "claimed", your tracker has no atomic claim. With GitHub Issues:

   bash

   Copy

   for i in $(seq 1 20); do
     ( if [ "$(gh issue view 42 --json assignees -q '.assignees | length')" = 0 ]; then
         gh issue edit 42 --add-assignee @me >/dev/null && echo "worker $i: claimed"
       fi ) &
   done; wait

   The Linear version we ran is public: ./reproduce.sh linear in the benchmarks folder (it needs a LINEAR_API_KEY for a scratch workspace and writes 15 issues there). The script is scripts/linear_tasks.py. The Radial race is scripts/radial_race.py; it needs 20 agent keys and writes to the workspace behind them, so point it at a test workspace. ./reproduce.sh offline runs the no-tracker baseline with no network and no credentials.

2. Decide who hands out the work. If a human or an orchestrator assigns each issue to one agent, a failed race does not hurt you: pick for delegation and integrations (Linear, or Jira if you are already on it). If agents claim from a shared queue, you need an atomic claim: Beads inside one repo, Radial for a team, or a lock outside the tracker. The parallel agents guide covers the orchestrator side.

3. Check the agent's surface and the close. Agents in a shell need an official CLI with JSON output (gh, acli, bd, radial). Agents in an MCP client need an MCP server (all seven have one). Then close one issue with proof and check that a human can read it without opening the repo.

#Methodology

• Live Linear, 2026-11-02: tools/list against mcp.linear.app/mcp, server 1.0.2 (L-LIVE-MCP-TOOLS); the 6-call flow over MCP, n=5, scripted with no model time (L-LIVE-T1T4); the claim race, 20 workers x 10 rounds, read then issueUpdate, one API key, in a scratch workspace (L-LIVE-RACE).
• Live Radial: tools/list against mcp.radial.build/mcp, 2026-11-02 (R-LIVE-MCP-TOOLS); the claim race, 2026-11-04, 20 workers x 10 rounds, one conditional POST /api/v1/issues/{id}/claim per worker, 20 distinct agent keys, on production in Radial's own internal workspace, each issue unassigned and read back before its round (R-LIVE-RACE). A first race run without the unassign step was discarded (all 200 claims got a 409). No live Radial task run.
• Baseline: python3 scripts/baseline.py runs/2026-11-02/baseline --n 10, scripted agents in temp git repos; token trials with scripts/cc-trials.sh 3, Claude Code on Sonnet, n=3.
• Coverage: 19 rows from coverage-matrix.md, generated by scripts/build_matrix.py. Radial from source at commit 9126321; Linear and Jira from docs.
• Docs-only: Jira, GitHub Issues, Beads, Plane and YouTrack. No live run against any of them.
• Screenshots: terminal images render real command output; page images are headless Chromium captures of public pages on Nov 4, 2026, cookie banners declined. We had no sanctioned test workspace to capture Radial's app UI, so this post shows none.
• Not measured yet: a live Jira run, a multi-identity Linear race and a live Radial task flow. Nothing here claims one tracker is faster per task than another.

#FAQ

#What is the best issue tracker for coding agents?

It depends on who hands out the work. If humans or an orchestrator assign each issue to one agent, Linear has the best delegation and agent integrations, Cursor included. If agents claim their own work from a shared queue, pick a tracker with an atomic claim: Beads for one repo, Radial for a team that also wants a board. Run the claim race in "How to choose" on your current tracker first.

#Does Linear have a CLI?

No official CLI for issues. Linear ships two narrow official CLIs, linear-release and a CLI Importer. Agents reach Linear issues through its MCP server at mcp.linear.app/mcp (60 tools, measured live on 2026-11-02), the GraphQL API, or a community CLI such as schpet/linear-cli, maintained outside Linear.

#Should agent tasks live as markdown in the repo or in a tracker?

Markdown in the repo works while one agent works alone. It breaks under concurrency: in our scripted runs, two agents claiming the first open task from one shared TODO.md lost a claim silently in 20 of 20 trials, and two branches that both appended a task conflicted in 10 of 10 merges. Move to a tracker when a second agent or a teammate needs the same list. Beads keeps the in-repo feel with a database and a claim command; the git issue tracker post covers that middle ground.

#Can two agents grab the same issue?

Yes, on any tracker where a claim is a plain assign. In our live Linear race, 20 workers per round over 10 rounds, more than one worker was told "claimed" in 10 of 10 rounds, and 183 claims were silently overwritten. GitHub Issues, Jira, Plane and YouTrack document no conditional claim, and we have not raced them. Beads documents bd update <id> --claim as atomic. Radial's claim lets exactly one agent win and returns a 409 to the rest. In our live Radial race on 2026-11-04, 20 agent keys per round over 10 rounds, exactly one worker was told "claimed" in each round, 190 got a 409, and 0 claims were silently overwritten. The two races differ in method: Linear's used one API key with read-then-update, Radial's used 20 identities and a conditional claim that sets only the assignee. For the Radial agent loop, see the issue tracker for AI agents post.

#Are coding agents billed as seats?

Not on Linear ("Agents are not counted as billable seats in Linear"), Radial, or Plane for installed agents. Jira does not bill service accounts (5 free) or an agent on a person's token. GitHub Apps are not on GitHub's list of billed users, though GitHub does not address agents directly. YouTrack does not document it, and each standard user takes a license. Beads has no service to bill. Credits are a separate meter: Jira Rovo, Linear AI credits and Plane AI credits all exist.

#Which trackers work offline for agents?

Beads, which is offline-first: queries run against a local database, and you sync through your git remote when you choose. Linear has an offline mode, but its docs call it "a failsafe and not a full-fledged feature." Radial needs the network for every read and write, and GitHub Issues, Jira Cloud, Plane Cloud and YouTrack Cloud document no offline mode. Plane and YouTrack can be self-hosted, which keeps the data on your network but still needs that server.

#Where to start

If your agents claim their own work, see Radial pricing: $50 per human user per year, agents not billed as seats.