Vibe Kanban: a kanban board for running Claude Code, Codex and other coding agents

What Vibe Kanban does with a coding agent's work

A coding agent runs in a terminal and leaves a diff behind. Once you run three of them at the same time, the hard part stops being the prompt and becomes bookkeeping: which agent is on which branch, which diff you already read, which one you told to change the error handling. Vibe Kanban is built around that bookkeeping. The README frames the premise directly: engineers spend most of their time planning and reviewing agents, so the tool puts a kanban board in front of the agents and a review surface behind them.

The target user is an individual developer or a small team that already has Claude Code, Codex, Gemini CLI, Amp or one of the other supported agents installed and authenticated. The board is where issues are created, prioritised and assigned, privately or with a team. When an issue is ready, you create a workspace, and the workspace is what the agent actually runs in.

It is not an agent. It does not write code by itself and it does not replace the CLI you authenticate with. Everything it shows you comes from an agent you already had.

Workspaces, worktrees and the Rust crates behind the board

The unit of execution is the workspace. According to the README, each workspace gives an agent a branch, a terminal and a dev server. That maps onto the repository layout: Cargo.toml lists crates/worktree-manager and crates/workspace-manager as separate members, alongside crates/executors, crates/git and crates/git-host. The worktree crate is the mechanism, not a detail. A git worktree gives each workspace its own checkout on its own branch while sharing one object store, which is how parallel agents avoid writing into the same files.

Around that sit crates/server (an axum service, judging by the workspace dependencies) and crates/db for persistence, plus crates/mcp for the Model Context Protocol server. The web app is split into packages/local-web, packages/remote-web and packages/web-core, and the whole thing is packaged for npm through npx-cli/bin/cli.js. The Dockerfile shows the two-stage build: a node:24-alpine stage that builds packages/local-web, then a rust:1.93-slim-bookworm stage that compiles the workspace.

The worktree choice has a cost the README does not dwell on. Each workspace is a real checkout on disk, and the environment table includes DISABLE_WORKTREE_CLEANUP, described as disabling all git worktree cleanup including orphan and expired workspace cleanup. That variable exists because cleanup happens, and because sometimes it should not.

Installing Vibe Kanban and opening your first workspace

The README's installation section is two steps. Authenticate with your preferred coding agent first, then run the package from npm. There is no separate installer and no global binary to manage.

npx vibe-kanban

The package.json confirms the bin entry: the name is vibe-kanban and it points at npx-cli/bin/cli.js. Running the command starts the application, and the README's own summary of the loop is "One command. Describe the work, review the diff, ship it." You should see the board in the browser, with a blank database copied from the dev_assets_seed folder when running through the dev server.

If you are running it on a server behind nginx, Caddy or Traefik instead of on your laptop, the README is explicit that API requests are rejected with 403 Forbidden unless the origin is allowed. Set the origins your frontend is actually served from:

VK_ALLOWED_ORIGINS=https://vk.example.com

For several origins, the README gives a comma-separated form: VK_ALLOWED_ORIGINS=https://vk.example.com,https://vk-staging.example.com. The same section notes that when HOST is 0.0.0.0 on Windows, MCP_HOST should be set to 127.0.0.1.

Building from source is a different path. The README lists Rust stable, Node.js 20 or later and pnpm 8 or later as prerequisites, then pnpm i, then pnpm run dev, which starts the backend and the web app together. On macOS there is a ./local-build.sh script, and the README says to test the result with cd npx-cli && node bin/cli.js.

Where Vibe Kanban stops being the right tool

The README opens with a statement that changes how the whole page should be read: Vibe Kanban is sunsetting, with a link to a shutdown announcement. The last push to the repository was on 2026-04-24, and the newest release listed is v0.1.44 from the same day. A project whose own README announces its shutdown is not a foundation. If your plan involves depending on it for a year, the plan is wrong.

The second boundary is the worktree model. Parallel workspaces mean parallel checkouts, and repositories with large binary assets, submodules, or build steps that assume a single working directory will feel that cost. The README does not document rollback behaviour for a workspace whose agent went in a bad direction, and it does not document what happens to uncommitted changes when cleanup runs. DISABLE_WORKTREE_CLEANUP is documented as a debugging switch, which tells you the default is to clean up.

Third, the cloud-shaped features are the least safe to build on. VK_SHARED_API_BASE, VK_SHARED_RELAY_API_BASE and VK_TUNNEL configure a remote API and a relay tunnel, and the repository carries a large relay crate family. Those depend on a hosted service. The self-hosting guide exists, but self-hosting a client of a service that is shutting down is not the same as self-hosting the service.

Vibe Kanban compared with plain git worktrees and a terminal

The honest alternative is not another kanban board. It is the workflow Vibe Kanban formalises: you run git worktree add yourself for each task, open one terminal per worktree, and review with git diff. That approach has no sunset date, no npm package and no board. What you lose is the review loop. Vibe Kanban's README describes leaving inline comments on a diff and sending that feedback directly to the agent without leaving the UI, plus a built-in browser with devtools, inspect mode and device emulation for previewing the app. Reproducing that with worktrees and a terminal means switching windows for every comment, and the agent has no structured place to receive it.

A second comparison is against the agent CLIs themselves. Claude Code, Codex and the rest already have their own session management. Vibe Kanban's value is that it sits above all of them: the README lists more than ten supported agents, including Claude Code, Codex, Gemini CLI, GitHub Copilot, Amp, Cursor, OpenCode, Droid, CCR and Qwen Code. If you only ever use one agent and one task at a time, the board is overhead, and the agent's own interface is enough.

The real difference from a plain worktree setup is where state lives. Worktrees and a terminal keep state in your head and in your shell history. Vibe Kanban puts it in crates/db behind an axum server, which is why issues, workspaces and diffs survive a restart, and also why a database and a running service are now part of your development loop.

Licence, maintenance and what an upgrade costs

The repository is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are kept. That is a permissive licence, and it means the code you have today stays usable on those terms even after the hosted service goes away. It does not give you the trademark, and it does not oblige anyone to keep publishing releases. This is not legal advice; read the LICENSE file in the repository root for the actual terms.

The maintenance picture is concrete. The last push was on 2026-04-24. The newest release is v0.1.44, tagged the same day, following v0.1.43 on 2026-04-17 and a pre-release v0.1.42 on 2026-04-10. The README states the project is sunsetting. There is no documented migration path in the README, no successor project named, and no statement about how long the npm package stays installable. Upgrading past v0.1.44 is therefore not a question of cost but of whether a later version exists at all.

If you fork it, the build is not trivial. The Dockerfile pulls in build-essential, libclang-dev, libssl-dev and pkg-config, and the Rust workspace has around thirty members. The frontend is a pnpm workspace with three packages. Budget for that before treating the Apache-2.0 grant as a free continuation.

Editorial conclusion

Adopt Vibe Kanban if you already run several coding agents in parallel and want their branches, terminals and diffs in one board, and if you accept that the README states the project is sunsetting, so no upgrade path is promised. Do not adopt it as the backbone of a team workflow, and do not expect the cloud or relay features to carry you. Verify first that your agent CLI is authenticated, that git worktrees behave in your repository, and whether the features you depend on live in the open source crates or in the hosted service that is going away.

Frequently asked questions

Official sources

1. BloopAI/vibe-kanban on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases