Vibe Kanban and Claude Code: What a Kanban View Adds to Agent Work

Vibe Kanban is an open-source app that puts coding agents on a kanban board. You write an issue, start a workspace for it, and Vibe Kanban runs an agent such as Claude Code in its own git worktree on its own branch; when the agent finishes, you review the diff, send comments back, and open a pull request. The kanban view adds one thing agents badly need: a single screen showing every piece of agent work, what state it is in, and which diffs are waiting for you. It is built around the developer running the agents. A shared team board answers a different question — who may change what, and who did — for people who never open a terminal.

What Vibe Kanban is, and who makes it

Vibe Kanban was built by Bloop (BloopAI on GitHub↗ (opens in a new tab)) and is released under the Apache 2.0 licence. You start it with one command, which opens a local web app; you need to have signed in to at least one coding agent first. Its documentation lists more than ten supported agents, including Claude Code, Codex, Gemini CLI, GitHub Copilot, Amp, Cursor’s agent CLI, OpenCode and Qwen Code. It says plainly that it is not a coding agent itself: it runs the ones you already use.

npx vibe-kanban

Its situation changed in 2026, and it is worth knowing before you adopt it. In April 2026 Bloop announced↗ (opens in a new tab) that the company was closing and that Vibe Kanban would continue as an open-source, community-maintained project. The hosted cloud features — shared issues, projects and organisations — were to be withdrawn after 30 days, while local workspaces keep working, and the README still links a guide to self-hosting the cloud part with Docker. The repository remained active through September 2026. Check its README for the current state when you read this.

How it runs agents

The unit of work is an issue, and the documentation↗ (opens in a new tab) is explicit that an issue’s description becomes the prompt the agent receives. Running an agent on it means creating a workspace:

• Vibe Kanban creates a git worktree↗ (opens in a new tab) — a separate working directory — so the agent’s changes never touch your main checkout. Worktrees go in a .vibe-kanban-workspaces directory, which you can move in settings.
• It creates a working branch from the target branch you choose, with a generated name such as vk/abc123-add-login-page. Changes reach the target only through a pull request and merge.
• Each workspace gets a terminal and a dev server, and a built-in browser preview with developer tools.
• A workspace can hold several repositories and several agent sessions, and one issue can have several workspaces — useful for running agents in parallel on different parts of a feature, or for trying two approaches.

When the agent finishes, the changes panel↗ (opens in a new tab) shows the diff file by file, unified or side by side. You leave inline comments and send them to the agent, which works on them in the same workspace. That review-and-fix loop repeats until you are satisfied, then you open a pull request from the same screen.

Vibe Kanban also runs a local MCP server↗ (opens in a new tab), started with npx -y vibe-kanban@latest --mcp, so an agent — including one running inside a workspace — can list, create and update issues and start workspaces. The documentation notes it is local-only and cannot be reached from a public URL.

What the kanban view adds

Run one Claude Code session and you do not need a board; you are watching it. Run five and the terminal tabs stop telling you anything. The documentation’s default columns show what the view is for:

• To do — work not started.
• In progress — an agent or a person is working on it.
• In review — the work is done and waiting for you.
• Done — completed and verified.
• Backlog and Cancelled exist too, hidden unless you switch to the All tab.

The column that earns its place is In review. Agents produce work faster than people check it, so the scarce resource is review, and a column that collects everything waiting for your eyes is the honest queue. The Vibe Kanban overview makes the same point: when engineers spend most of their time planning and reviewing agents, getting faster at planning and review is how you ship more. Priority levels from Urgent to Low, sub-issues with their own status, and a manual sort order round it out. The general case — how lanes change when agents do the work — is covered in kanban for AI agents.

How it differs from a shared team board

Vibe Kanban is an orchestration surface: its board exists so that a developer can start, watch and review agent runs. A shared board such as fenbs is a coordination surface: its members — people and AI assistants — agree what should be done, and it keeps a record of who did what. The differences follow from that.

• Where it runs — Vibe Kanban: on the developer’s machine, next to the code and the worktrees; local projects are stored on that computer. fenbs: a hosted service reached in a browser, on the phone app, or by an assistant over MCP.
• Who is on it — Vibe Kanban: the developer, plus teammates when the cloud or a self-hosted instance is used. fenbs: members who each hold a role; a role can be as narrow as see and comment only.
• What an assistant may do — Vibe Kanban: agents run with the permissions you configure in their profiles, on your machine. fenbs: each assistant connection carries scopes (read, write, comment), acts as the person who approved it, and can be revoked on its own.
• Record — Vibe Kanban: the workspace’s conversation, the branch and the pull request. fenbs: a history of every change with who made it, an assistant’s changes shown as “Claude via” that person.
• Running agents — Vibe Kanban: yes, that is its purpose, with worktrees, terminals and diff review. fenbs: no. It does not start agents or create worktrees; an assistant you run connects to it and reads and writes tasks.

The lanes differ too. A fenbs board has four fixed lanes — To Do, Next Up, In Progress, Completed — with no review lane and no per-lane limits to configure. Review on a fenbs board is a convention you write down: the assistant comments what changed and how it was checked, and a person moves it to Completed. An AI agent task board sets out what else a board needs once assistants are members.

Using the two together

They sit at different levels, so they combine without much friction. The shared board holds what the team has agreed to build and in what order; Vibe Kanban holds the runs that build it.

1. People plan on the shared board: a task with a Problem, a kind and a priority, moved to Next Up when it is ready.
2. The developer who picks it up creates a Vibe Kanban issue from it, puts the board task’s ref in the title, and starts a workspace. Parallel attempts stay inside Vibe Kanban, where they belong.
3. When a diff passes review and the pull request is open, the result goes back to the board task: a comment with the pull request and the check that was run, and a move to the next lane.

What to avoid is running two boards at the same level: mirroring every issue, sub-issue and column change into the shared board. Let the shared board carry outcomes and decisions, and the agent board carry runs. If you run several Claude Code sessions without an orchestrator, running Claude Code tasks in parallel covers worktrees and claiming directly, and a kanban board for Claude Code covers how Claude pulls ready work from a board.