kdlbs/kandev

If you already run coding agents in a terminal and have hit the limit of reviewing their diffs one at a time, Kandev is worth a look. It is not a new coding model or assistant; it is a control surface around agents you already have installed.

The problem

A developer wants to push a handful of tasks through different coding agents and still understand every change before it ships. Today that often means several terminal tabs, each agent rewriting the same checkout, and review happening by scrolling raw output. Kandev changes that step: each task gets its own worktree and a small workspace with a file tree, editor, terminal, preview and git changes panel. Tasks live on a kanban or pipeline board, and the result is a queue of agent-produced changes that a human can inspect in one place.

What's different

Kandev's core mechanism is the ACP (Agent Client Protocol) integration. Instead of building its own agent, it launches the CLI of whichever tool you already use — Claude Code, Codex, Copilot, Gemini CLI and many others are listed — inside an executor. Executors can be a local process, Docker, Kubernetes, SSH or a remote cloud environment, and profiles bundle prepare scripts, environment variables and credentials for reuse. Worktree isolation keeps concurrent agents from stepping on each other's files, and a workflow can assign different agents to different steps, such as one to plan and another to review.

The benefit is breadth: the same board can mix providers, and automations can launch tasks from schedules or webhooks. The trade-off is that Kandev sits on top of a lot of moving pieces. Each supported agent still needs its own CLI installed and authenticated, and the most valuable behavior — worktrees, isolation, executors — depends on your git and runtime setup being correct. This is infrastructure for agent work, not a single binary that removes the need to configure agents.

Who should try it

It fits a developer or small team that already has two or three agent CLIs working locally and wants to run them in parallel on separate branches, then review diffs side by side. It is also aimed at people who want opinionated, shareable workflows rather than ad-hoc prompting. It is a poor fit if you run one agent occasionally, work mostly in a single checkout, or dislike managing a server, agent credentials and executor profiles. The self-hosted distribution helps teams that want to keep code and sessions on their own machines, but it means someone owns the deployment and updates.

Requirements and limitations

You need the agent CLIs you intend to use, plus whatever runtime your chosen executor requires: Docker for containers, Kubernetes access for pods, SSH targets for remote sessions, or local tools for the default process executor. Git worktrees and a SQLite database live under ~/.kandev by default, so disk layout and backup are yours to manage. The native Go binary embeds the web frontend, which means no Node.js is needed for the application server; only the npm/npx launcher adds a Node.js requirement. Platforms are macOS, Linux and Windows via WSL or native, but third-party agents have their own prerequisites — Cursor, for example, is listed as requiring Cursor Pro.

Office mode, the persistent agent-team layer with roles, budgets and approvals, is explicitly experimental and disabled by default; the project itself says it is not yet a stable production contract. Treat it as a preview rather than a foundation for team process.

HotRepo's take

HotRepo has only one dated observation for this repository: on 2026-10-25 it stood at 1,006 stars with +4 that day and appeared on the daily trending board. With one recorded sample, persistence cannot be judged, so the lasting value is the question rather than the trend. The specific thing to verify before adopting is the executors documentation: confirm that the executor you plan to use supports the credentials and storage model your team already has, because that compatibility, more than the agent list, determines whether the parallel workflow is practical.