kanbots: a kanban board that dispatches coding agents in parallel

Cards become agent runs

The project describes itself as a kanban board that runs 11 agent CLIs in parallel, and the mechanism is direct enough to explain in a sentence: you drop a folder, you get a board, and you dispatch agents on every card, at the same time, each in its own worktree. The board itself is a five column layout running from Backlog to Done, plus an Inbox for cards that have no label yet, and cards are dragged between columns. There is also an autopilot mode, described as letting the agents split tasks, run them in parallel slots and check their own work. Two integrations sit on top of the board. Sentry import pulls error groups onto the board for triage, with one click handing an issue to an agent, and an MCP server named kanbots-mcp-server exposes the board over the Model Context Protocol so Cursor, Claude Desktop or anything MCP-aware can drive it. The pitch is that a team already paying for agent CLIs gets a supervisor rather than a new model.

The agent list is longer than the sign-in list

The supported agents table is the most useful part of the documentation, because it tells you exactly what has to be on your PATH. Claude Code runs as claude with claude /login, Codex as codex with codex login or OPENAI_API_KEY, Gemini as gemini with gemini auth, the Cursor CLI as cursor-agent with cursor-agent login, GitHub Copilot CLI as gh-copilot with gh auth login and a Copilot subscription, Amp as amp, OpenCode as opencode, Droid as droid with a Factory account, CCR as ccr, which reuses Claude Code authentication and routes to alternative models, and Qwen Code as qwen. Then there is the catch-all row, any ACP-compatible CLI, where the binary is yours and kanbots speaks the Agent Client Protocol over stdio. The sign-in model is the important design decision here. You do not sign into kanbots, kanbots calls the CLI that is already authenticated on your machine, so credentials stay in the tool you already trust and the board itself holds no agent tokens. You need at least one agent CLI installed, and the CLI is chosen per dispatch from the New Task modal.

One worktree per run, and a hook that stops the push

The run lifecycle is where the safety of the design lives. Clicking Dispatch creates .kanbots/worktrees/issue-<n>-<runId>/ branched from the repository's default branch. The application then spawns the CLI against that worktree, with claude -p or codex in exec mode, using stream-JSON output, parses every event and forwards it to the interface. When the run finishes or you stop it, the worktree stays on disk, and you choose what happens to it: start the dev server in the worktree as a branch preview and open a live URL, promote the worktree into a real commit on your branch, open a draft pull request in GitHub mode, or discard the worktree and its branch. A pre-push hook is installed in every worktree so an agent cannot push to a remote on its own, and promotion is always an explicit user step. Everything else an agent does is sandboxed by the worktree boundary, which is what makes running eleven agents at once tolerable.

Decision prompts interrupt the run in the UI

Agents that work unattended eventually need a decision, and how that question is handled separates a usable tool from a log file. Every tool_use and tool_result streams into the interface as a live agent thread, and when the agent requests a decision the run pauses and a card appears in the UI. You answer by clicking an option and the run continues from where it stopped. The issue detail view adds a few things that matter in practice, run statistics covering the model, elapsed time, tokens and cost, the worktree and branch information, check buttons, and a reply box that accepts slash commands such as /spec, /review and /split. The cost and token counters are worth noting because parallel agents multiply spend, and having the figure on the card is the difference between a budget you can watch and one you find out about afterwards.

Local SQLite issues or GitHub issues

The board has two workspace modes and the choice is about where your issues live. In local mode the issues are stored in SQLite in .kanbots/db.sqlite, which suits solo work, side projects and any repository where you do not want GitHub Issues involved. In GitHub mode the board talks to the GitHub REST API through Octokit, for when the issues already live on the repository. The full directory layout shows the extent of what is written locally. Inside .kanbots you have db.sqlite holding all issues, threads, runs, providers and settings, config.json for the workspace mode and defaults, a worktrees directory with one subdirectory per agent run, an attachments directory for files dragged into chats or cards, an mcp-runtime directory for the transient MCP configs handed to Claude or Codex, and a promote directory that stages a worktree on its way to a commit. The documentation states that nothing is written outside this directory or the worktrees it creates, which is a useful property to be able to state about a tool that runs agents on your files.

Installing means dealing with unsigned builds

The recommended install is one command:

npx kanbots

On first run the right binary downloads automatically, around 80MB, from the releases page, and the app opens. Upgrading later is npx kanbots@latest. macOS arm64 and x64 and Linux x64 are fully automated, while on Windows the npx launcher points you at the .exe installer for v1. The packaged builds are less friendly. The macOS .dmg is unsigned, so Gatekeeper rejects it on first launch with a message saying kanbots is damaged and can't be opened, and the workaround is a one line install script that grabs the right .dmg, clears the quarantine flag and copies the app into /Applications:

curl -fsSL https://kanbots.dev/install-mac.sh | bash

If you prefer to do it by hand you can download the .dmg, drag the app into /Applications and run xattr -d com.apple.quarantine /Applications/kanbots.app once. Linux ships an .AppImage you chmod +x and run, or a tar.xz, and the Windows .exe installer triggers a SmartScreen warning that you dismiss with More info and Run anyway. Running from source needs Node 20 or newer, pnpm 10 or newer, git and at least one agent CLI:

git clone https://github.com/leodavinci1/kanbots.git
cd kanbots
pnpm install
pnpm desktop

The desktop:dev script gives you a hot-reload loop with Vite, tsup in watch mode and electronmon.

A pnpm workspace with an Electron shell and a SQLite engine

The repository is a pnpm workspace rather than a single package, and the root manifest is marked private with a version of 0.0.0, since the published artefacts are the per-package releases. It declares Node 20 or newer and pins pnpm 10.32.1 as the package manager, and the scripts fan out across the workspace with pnpm -r for build, dev, test and typecheck, plus lint, format and release tasks. The desktop script launches the @kanbots/desktop package, and the pnpm configuration lists better-sqlite3, electron and esbuild as the dependencies allowed to run install scripts, which is the modern equivalent of the old postinstall allowlist. The workspace holds the packages directory, the npx-cli directory for the launcher, the docs directory and an eslint config, with prettier and editorconfig files at the root. The project is MIT licensed, the releases are v1.0.1 on 2026-05-22, v1.1.0 on 2026-05-23 and v1.2.0 on 2026-05-25, and the last push was on 2026-05-25 with the repository not archived.

Editorial conclusion

Adopt kanbots if you already run coding agents from a terminal and want to supervise several of them at once with reviewable diffs, since it isolates every run in a worktree and blocks pushes. Do not adopt it to replace a project tracker, because the board only knows the two issue sources it ships, and note that the macOS and Windows builds are unsigned, so expect a Gatekeeper or SmartScreen step on first launch.

Frequently asked questions

Official sources

1. leodavinci1/kanbots on GitHub
2. License: MIT
3. Project website
4. README
5. Releases