Kandev: running AI coding agents from a task board, even from bed

Published 12 October 2026 · Alex Usharovski

Not long ago, my work with AI coding agents looked like this: a cloud VM, tmux on it, five or six windows inside. In one, Claude Code is fixing an Android app; in another, Codex is reading a diff; in a third, Gemini is researching something; in the rest, I no longer remember what. It worked. But more and more often I caught myself not writing code, not even thinking about the problem, just walking from window to window to see which agent was waiting for me.

Now all of that lives in Kandev. Here is which of my problems it solved, how to set it up, and why I picked it over the other options.

What was wrong

The agents were not the problem. Everything around them was.

• You can't see who is waiting. An agent does half the job in five minutes and asks a question. Its window is somewhere in tmux. I find out an hour later, when I happen to look.
• Agents get in each other's way. Two agents in one working tree means, sooner or later, someone else's uncommitted file in your commit, or a branch switched under a neighbour's feet.
• A terminal is not made for a phone. Over SSH from a phone, everything is technically reachable. In practice, typing a reply to an agent in a mobile terminal is painful, and reading a diff there is close to impossible.
• It all lived in my head. Which task is in progress, which is waiting for review, what I have checked and what I have not. A head is a poor place for that.

What Kandev is

Kandev is a task board, like Trello or Jira, where the assignees are AI agents. It is open source (AGPL-3.0), self-hosted, with no telemetry. The backend is a single Go binary; the interface opens in a browser.

What it looks like in practice:

• A task is a card. I write it the way I would message a colleague: what is wrong, what I want, what matters. I pick a repository and an agent. From there the agent works on its own.
• Every task gets its own copy of the repository (a git worktree) and its own branch. Agents do not edit the same files or switch branches on each other, and I can keep five tasks in one project going at once.
• Many agents, not just one vendor. Claude Code, Codex, Copilot, Gemini CLI, OpenCode, Auggie, Cursor and a dozen and a half more. Most connect through ACP, the Agent Client Protocol, an open protocol between an agent and an interface. Kandev does not swap your agent for its own: run locally, it is the same Claude Code you use in a terminal, with the same rules files, skills and MCP servers.
• Columns are statuses. In my workflow, when an agent finishes its turn, the card moves to "Review". I see it right away, not an hour later.
• Review is built in. Diff, files, a terminal in the same copy of the repository, a preview, all in one window. The PR is opened from there too.
• The agent can work with the board. Kandev gives the agent its own MCP tools: it can rename the task, save a plan, ask me a multiple-choice question, or create a subtask. The question shows up in the interface instead of getting lost in some window.

On paper it is an ordinary task tracker. In practice it changed my working day quite a bit.

Development from bed

The most useful part turned out to be something I did not expect. Kandev runs on a cloud VM and opens in a browser, so I can run development from anywhere. Including from my phone, lying in bed.

In the evening I write a couple of tasks on my phone. Not code, just plain human text, sometimes with typos; the agents understand them perfectly well. In the morning I look at the "Review" column: what is done, what the agent checked, where it is unsure. I answer questions, ask for fixes, approve. I open the laptop when I need to look at something closely or think about architecture.

The phone does not get a cut-down version: same diff, same chat, same plan. The agent does not care where the reply came from, and all the compiling and testing happens on a machine with 32 GB of memory, not on the phone.

I did not start working around the clock; if anything, the opposite. Before, answering a one-word question from an agent meant walking over to the computer. Now I answer and go back to whatever I was doing.

How to set it up

I will describe my setup: a Linux VM in the cloud, reachable only through Tailscale. If you only want Kandev on your own laptop, the first step is enough.

1. Install. I used npm. Kandev itself is a Go binary with the interface built in; it does not need Node.js to run:

npm install -g kandev@latest
kandev

Without Node.js you can use brew install kdlbs/kandev/kandev (macOS and Linux) or Scoop on Windows. On first start, Kandev creates a workspace, a "Development" workflow and two executors: local and Worktree.

2. A service. On a server, Kandev should live on its own, not inside my SSH session:

# a systemd user service
kandev service install
# keep running when logged out
sudo loginctl enable-linger "$USER"

3. Access from outside, for me only. The VM is in my Tailscale network, and Tailscale Serve gives Kandev an HTTPS address that only my devices can reach. First, bind Kandev to localhost and pin the port: by default it listens on all interfaces, and if port 38429 is taken it picks a random one. For the service that is two lines in override.conf (systemctl --user edit kandev):

[Service]
Environment=KANDEV_SERVER_HOST=127.0.0.1
Environment=KANDEV_BACKEND_PORT=38429

Then Tailscale Serve:

tailscale serve --bg --https=8443 http://127.0.0.1:38429

My phone has the Tailscale app, and an address like https://<machine>.<tailnet>.ts.net:8443 opens like any website. Agents in Kandev run commands on the server, and anyone who reaches Kandev without signing in is an administrator. So do not expose it without a VPN, Cloudflare Access or Kandev's own authentication turned on.

4. Agents. Settings → Agents: Kandev finds the installed CLIs by itself. Each CLI signs in once, its usual way (subscription, OAuth or API key), in a terminal on the server, as the same user Kandev runs as.

5. Repositories. Settings → Workspaces → Repositories → Add repository. You can also set scripts that run when a copy of the repository is created, for example npm ci.

6. First task. New Task, pick the repository and the agent, keep the Worktree executor, write what needs doing. Then watch the agent work, and do not rush the PR until you have checked the result yourself.

Rakes I stepped on

• The service does not see your PATH. Systemd does not read ~/.profile. Kandev adds a couple of standard folders itself, but if your agents and Node.js live somewhere else, the service will "not find" them. The fix is the same override.conf with its own Environment=PATH=....
• After an update, reinstall the service. I update with npm install -g kandev@latest, and after that kandev service install has to run again, followed by kandev service restart: the unit file records the version and the path to the binary. Your override.conf is kept. I have a small update.sh that does it all at once. Newer versions can also update themselves from Settings → System → Updates.
• Not every agent speaks ACP. Some need an adapter or a wrapper. For one agent I had to make my own.
• The agent's environment is not your terminal. For example, on my machine, inside Kandev sessions the global npm prefix points to a temporary folder, so npm install -g puts packages there. If an agent installs tools for itself, have it pass an explicit --prefix.
• Share common resources explicitly. A worktree separates the code, not the machine. The Android emulator, dev server ports and memory for builds are shared. The rules file every agent on my VM reads says: there is one emulator, check whether it is already running first; never kill someone else's processes; take ports above 3000. Without that, agents will get in each other's way sooner or later.
• Repository copies take space. Worktrees share git history, but the files, node_modules and build output are separate for every task. Archive old tasks: Kandev then removes their copies.

Why it beats almost every alternative

Plenty of tools for parallel agents have appeared over the past year. I have looked at the main ones. Briefly, how I see them:

• Claude Squad is a TUI on top of tmux and worktrees. Light and honest, but it is still a terminal. Awkward from a phone, and there is no task board.
• Conductor is a polished app with good diff review. But it is Mac only, closed source, and supports a handful of agents: Claude Code, Codex and Cursor. And you can only look at the work from the Mac it is installed on.
• Vibe Kanban is the closest to Kandev in spirit: a task board, worktrees, many agents. But the company behind it wound down in spring 2026, and the project's future now depends on the community.
• Emdash is the most serious rival: open source, dozens of agents, and it can run them on a remote machine over SSH. But it is a desktop app: the agents can live on a server, yet you can only watch them from the computer the client is installed on. Not from a phone.
• Cloud agents (Claude Code on the web, Codex cloud, the Copilot coding agent) need no setup and work from a phone. But each lives on its own platform, and the code runs in someone else's cloud. The environment there has to be rebuilt and maintained separately, and an Android emulator with my already configured tools will not appear there by itself.

For me it was not one feature that decided it, but the combination:

• It is a server, not an app. It runs where the resources and the environment are, and I look at it from wherever I am. Laptop closed, agents still working.
• Different agents, mixed freely. One writes, another reviews, a third researches. If one runs out of quota, another picks up the task. No lock-in.
• My environment is their environment. The agents work on my machine with my tools and my rules. CLAUDE.md and AGENTS.md files work as they are; nothing needs to be moved.
• The code and the data are mine. Open source, self-hosted, no telemetry.
• Tasks, not windows. Board, statuses, plans and agents' questions in one place. Exactly what the terminal was missing.

Where it falls short

Kandev has its downsides too:

• The learning curve. It is a tool for people who are willing to configure things: agents, executors, workflows, profiles. There are many settings, and not all are obvious. If you need one agent on one laptop, Kandev is overkill.
• Young and moving fast. Releases come out often. Sometimes something breaks and an update means some digging. That does not bother me, but for a team I would pin the version.
• Resources. Five agents in parallel, each with its own build, is real load. 8 cores and 32 GB are enough for me; a weak laptop will feel cramped.
• AGPL-3.0. Irrelevant for personal use. If you plan to modify Kandev and offer it to others as a service, read the license.
• An agent is still an agent. Kandev does not make agents smarter. It makes working with them easier. Checking the result and keeping rules and tests in place is still your job. I wrote about that in A one-person studio with an AI team.

Bottom line

If you work with one agent and are happy in a terminal, you do not need Kandev. If you have several agents and more than one task at a time, and you want to look in on the work from somewhere other than your desk, give it a try. It gave me back the feeling that I am running the work rather than running between windows. And being able to answer an agent from bed turned out to be not a gimmick but the most useful thing it gave me.

Links: Kandev repository, documentation.