# cline/kanban: A Local Board for Parallel CLI Agents

> cline/kanban is a research-preview TypeScript application for launching CLI coding agents in parallel, with isolated Git worktrees, task dependencies, diff review, and local Git controls. It suits developers who need an agent-focused workspace rather than a conventional IDE.

**cline/kanban** — Launch a local web app that runs CLI agents in parallel

- Repository: https://github.com/cline/kanban
- Stars: 1,368 · Forks: 335
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/cline-kanban

## What cline/kanban is built to coordinate

cline/kanban addresses a specific coordination problem: running several CLI coding agents against one repository without placing all of their work in the same working directory. Each task card receives its own terminal and Git worktree, so multiple agents can work in parallel while Kanban keeps their changes separated for review. The target audience is developers who already use CLI agents but need a task-oriented interface for distributing work, following progress, and deciding when to commit or open a pull request.

The README describes Kanban as a local web application and a replacement for an IDE in workflows involving many parallel agents. That positioning has a practical consequence. This is not merely a checklist with an agent field attached to it. The board controls where work runs, exposes status from the agent session, stores changes in separate worktrees, and provides a Git interface for branch and history operations.

Kanban also supports two automation paths. Cards can be linked so that a dependent task starts when the earlier card is completed and moved to the trash. Auto-commit can then turn that sequence into a chain in which one task completes, commits, and starts the next. These features make the project relevant to larger decompositions, such as separating a multi-part change into independent implementation tasks, but they also increase the importance of reviewing task boundaries before enabling automation.

## Worktrees, terminals, hooks, and linked cards

The central mechanism is the per-card ephemeral Git worktree. When a user presses the play button on a card, Kanban creates a worktree for that task and launches the agent there. The repository's gitignored files, including an existing `node_modules` directory, are symlinked into the new worktree. According to the README, this avoids repeating a slow `npm install` for each copy of the project.

The symlink approach is a deliberate performance and storage trade-off. It assumes that gitignored files are usually reused unchanged. The README specifically warns against Kanban when those files are modified during day-to-day work. A symbolic link does not copy an independent version of a dependency tree, so two tasks can still affect each other if they alter a shared gitignored file. This is a concrete boundary for evaluating the tool, especially in projects whose generated assets, local databases, or caches live in ignored paths.

Hooks provide the monitoring layer. The README says Kanban uses hooks to display the latest message or tool call on each card, which lets a user scan activity without opening every agent session. Clicking a card exposes the agent's TUI and a diff of the changes in its worktree. Kanban also records checkpoints, allowing a diff to be compared with the state after a previous message.

Task links are managed with the keyboard and card interface. The README instructs users to use ⌘ plus click to link cards. Once a linked predecessor is completed and moved to the trash, the next task auto-starts. Auto-commit can be added to that sequence, but the README presents this as autonomous execution rather than a replacement for review.

## Running cline/kanban from a Git repository

Kanban can be started without a global installation. Run the command from the root of a Git repository. The package requires Node.js `>=22`, and the package metadata identifies `kanban` as the executable exposed by the project. The README says Kanban detects the installed CLI agent, starts a local web server, and opens it in the browser.

The following command runs the package directly through `npx`:

```bash
npx kanban
```

The reader should run this from the repository that Kanban will manage, rather than from an unrelated directory. The README does not document a fixed port, authentication setup, or a separate configuration file for the first launch. It states that no account or setup is required.

For a global installation, use:

```bash
npm i -g kanban
kanban
```

The first practical action inside the web application is to create a task card manually. A second path is the sidebar chat, where the user can ask the agent to break work into tasks. Kanban injects board-management instructions into that session, according to the README. The initial workflow therefore depends on an already installed CLI agent, but it does not require a separate account or configuration wizard.

## Reviewing agent output and shipping worktrees

Kanban puts review in the same application that runs the agents. A card can display the agent's TUI, the complete diff for its worktree, and a diff from the last checkpoint associated with an earlier message. Lines in a diff can be selected for comments, and the comment can be sent back to the agent. This makes the review loop more direct than collecting terminal transcripts separately, although the README does not describe the exact checkpoint retention policy or storage format.

The README recommends creating a Script Shortcut in settings for recurring application commands. It gives `npm run dev` as the example command, after which the play button in the navbar can start the shortcut. This is useful for a repeated local development action, but the feature should be configured with commands that are safe to execute from the task worktree. The documentation does not claim that Script Shortcuts are sandboxed or that they can undo every external side effect.

When the diff is acceptable, the user can select `Commit` or `Open PR`. Kanban sends a dynamic prompt to the agent to turn the worktree into a commit on the base ref or a new pull request branch, including handling merge conflicts. The README also documents auto-commit and auto-PR as optional ways for the agent to ship completed work without a manual review step.

The branch name in the navbar opens a Git interface with commit history, branch switching, fetching, pulling, pushing, and graph visualization. Moving a card to the trash cleans up the worktree, while the README states that the task can be resumed later because Kanban tracks the resume ID.

## Research-preview limits and maintenance cost

The clearest limitation is stated in the README's warning: Kanban is a research preview and uses experimental CLI-agent features, including bypassing permissions and runtime hooks to provide more autonomy. Those capabilities can reduce interruptions, but they also change the trust boundary around agent execution. The README does not provide a formal permission model, audit format, rollback procedure, or production-readiness guarantee. Users who require a conservative approval boundary should verify those points before allowing long dependency chains or unattended shipping.

The project is not archived, and its last push was on 2026-10-09. Its recent releases listed in the repository context include v0.1.70 on 2026-07-12, v0.1.69 on 2026-07-06, and v0.1.68 on 2026-05-08. The package version in `package.json` is `0.1.70`. These are pre-1.0 version numbers, which fit the README's research-preview label. They do not establish a stable API contract.

The Apache-2.0 license permits use under its terms, but this review does not replace legal review of obligations such as notices and license text. Upgrade work should account for changes in experimental agent hooks, worktree behavior, and the web UI. The README does not document a migration guide for an existing board or a compatibility policy for earlier `kanban` versions.

## cline/kanban compared with an IDE-centered workflow

A conventional IDE workflow usually keeps one repository working directory and one primary agent conversation in view. cline/kanban takes a different approach: it makes a board the control surface and creates a separate ephemeral worktree for each task. That gives the project a clear advantage when several agents can work on independent changes at once, because each task has its own terminal, diff, checkpoint history, and resume state.

The trade-off is that the board assumes a repository-based task model. It depends on Git worktrees, branch operations, worktree cleanup, and a CLI agent that Kanban can detect. An editor-first workflow may be a better fit for a single continuous session, immediate access to a familiar set of panels, or tasks that depend on frequently changing ignored files. Kanban's symlinked dependencies can save installation time, but the README explicitly says not to use it when gitignored files are modified routinely.

cline/kanban is consequently closer to a local task orchestration layer for coding agents than to a general-purpose IDE replacement. It is most useful when the user wants to decompose work, start several agents, monitor compact status indicators, inspect diffs, and then commit or open pull requests from one place. It is less suitable when autonomous agent execution requires strict permission controls or when the project cannot tolerate pre-1.0 experimental interfaces.

## Conclusion

Adopt cline/kanban when your work is naturally divisible across Git-backed tasks and you want a local board for running CLI agents concurrently. Do not adopt it if agents must freely modify gitignored dependencies in each isolated worktree, or if you require a stable production interface without accepting the research-preview status. Verify first that Node.js 22 or newer is available, that your installed CLI agent is detected, and that your workflow is compatible with Kanban's symlinked gitignored files and experimental agent features.

## FAQ

### How do I run cline/kanban locally?

Run `npx kanban` from the root of a Git repository, or install the package globally with `npm i -g kanban` and run `kanban`. The README states that Kanban detects the installed CLI agent and launches a local web server in the browser.

### How does cline/kanban keep parallel agents from editing the same files?

The README says each task card receives its own terminal and ephemeral Git worktree. Agents therefore work in separate task locations, with Kanban exposing each worktree's diff for review.

### Can cline/kanban run task dependencies automatically?

Yes. The README says linked tasks auto-start when the preceding card is completed and moved to the trash. Adding auto-commit allows the sequence to continue by committing the completed task and starting the next one.

### What should I check before enabling auto-commit or auto-PR in cline/kanban?

Review the agent's changes first, because the README describes these options as ways for the agent to ship work as soon as it is done. Also check that the task boundaries, permissions, and experiment-dependent agent behavior are acceptable for your repository.

### Does cline/kanban require a separate account or setup?

The README says no account or setup is required for the initial launch. It does require an installed CLI agent that Kanban can detect, and the package metadata specifies Node.js `>=22`.

## Sources

- [cline/kanban on GitHub](https://github.com/cline/kanban)
- [Issues](https://github.com/cline/kanban/issues)
- [License: Apache-2.0](https://github.com/cline/kanban/blob/main/LICENSE)
- [README](https://github.com/cline/kanban/blob/main/README.md)
- [Releases](https://github.com/cline/kanban/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cline-kanban