Kandev
A self-hostable AI Kanban and development environment: orchestrate parallel coding agents, review changes, open PRs — with no telemetry and no vendor lock-in.
CI workflows explicitly implement least privilege (contents: read, persist-credentials: false, SHA-pinned actions, digest-pinned images); Docker/SSH executors and git worktrees isolate parallel agents; a dedicated poisoned-env job prevents accidental credential injection — full marks for least_privilege. Review-first gates, redacted Gist snapshots with revoke, and opt-in hostname resolution support user_confirmation and sensitive_data_handling at 2: real but evidenced mainly via tests and narrative, not product-level documentation of confirmation UX. No telemetry and self-hosting help transparency, but per-flow data handling with third-party agent vendors is not itemized — deduct 1. External effects (PRs, webhooks) are configurable behind review, yet safeguards against destructive remote actions from automations are not directly shown. Rollback: only session resume and a git changes panel are visible; no documented restore mechanism — 1. Attribution is clear (acknowledgments, AGPL, Discord/issues) but the publisher is unverified with no stated maintenance entity.
README, workflow comments, and e2e tests are mutually consistent on auth and merge-queue semantics, with candid disclosure of nightly and unpinned-runtime caveats — self_consistency 2. Dependency availability is partially handled: managed-runtime update mechanism, mise-pinned toolchain, prebuilt CI image; but agent runtimes are deliberately unpinned and rely on npm's best-effort cache, as documented. Failure handling is well evidenced in tests (asserted error strings; careful CI handling of cancelled vs skipped; fail-open logic explained), but product-level error documentation is absent from the provided files — 2.
Audience and scenarios are thoroughly described (power users, teams, remote/mobile access, multi-repo, multi-provider) — 3. Environment fit is strong: macOS/Linux/Windows, four install channels, multiple executors, pinned dev toolchain — 3. Capability boundaries are partly handled: Office mode explicitly declared unsupported, manual-install agents flagged; but hard limits (dangerous-command safeguards, sandbox boundaries) are not documented — 2. Trigger precision: schedules/webhooks expose concurrency, destinations, and context, but matching/dedup details are unseen — 2.
Information architecture is excellent (structured docs tree navigated from README) — 3. Install notes cover brew/scoop/npx/npm, updates, nightly semantics, source build with pinned prerequisites — 3. Naming is consistent (kandev, KANDEV_ env prefix) but versioning rests only on latest/nightly tags. Examples exist (screenshots, workflow-tips, add-agent guide) but no FAQ — 2. Limitations are candidly disclosed — 2. Full AGPL-3.0 text — 3. No CHANGELOG file is visible; history relies on npm tags — 1. Maintenance is signaled via issues/Discord/contributing but no maintainer commitments — 2.
Output usability is strong: integrated review workspace (editor, terminal, browser preview, git changes, PR linking), session resume, shareable snapshots — 3. Marginal value over TUI agents is concretely argued (review doesn't scale in terminals, remote offload, multi-provider, server-first) — 3. Cost/benefit: self-hosted, no telemetry is a clear benefit, but resource/API-cost tracking sits in the unbuilt Office roadmap — 2.
Major claims link to docs, and workflows plus e2e tests corroborate README security claims (cookie scoping, member isolation, anonymous WS rejection) — 2 rather than 3 because many feature claims (agent integration quality, Sprites, plugin marketplace) cannot be cross-verified in the provided files. Cross-source corroboration among README, CI comments, and tests is genuine but incomplete. Fact/inference separation is good: Office mode marked in-progress, K8s operator aspirational, iFlow beta — 2.
- This is a static source review with low confidence; no runtime verification was performed — reproduce installation, auth, and agent behavior yourself.
- Publisher identity is unverified: the kdlbs org cannot be confirmed via a curated registry; vet maintainership and supply chain (Homebrew tap, Scoop bucket, npm ownership) before production use.
- Agent runtimes are deliberately unpinned and rely on npm's best-effort cache; audit and pin upstream versions in integrity-sensitive environments.
- Automations (schedules/webhooks) can trigger agent execution and open PRs: grant minimal credentials and enforce review gates; avoid destructive remote permissions.
- No explicit rollback mechanism is documented: recovery from mistaken agent changes relies on worktrees/PR review — rehearse recovery paths yourself.
- If exposing the self-hosted web service, enable opt-in authentication (KANDEV_FEATURES_AUTH), use a private channel such as Tailscale/Cloudflare Tunnel, and keep the instance off the public internet.
What does this agent do, and when should you use it?
Kandev is an open-source AI Kanban and agentic development environment for power users who want deep control over how AI coding agents work. It consists of a Go backend (orchestrator, lifecycle, agentctl, WS gateway), a Vite/React frontend, an npx CLI launcher, and a Tauri desktop shell. Agents connect via ACP (Agent Client Protocol) — Claude Code, Codex, GitHub Copilot, Gemini CLI and 20+ others — and any agent CLI can also run as a TUI via CLI passthrough. Tasks execute in isolated Git worktrees through local-process, Docker, SSH, or sprites.dev executors. An integrated workspace bundles a terminal, LSP-enabled editor, file tree, browser preview, and git changes panel; the project is AGPL-3.0 licensed, runs locally or self-hosted, and supports remote access via Tailscale or Cloudflare Tunnel.
Kandev pulls issues into a kanban board (integrating GitHub, GitLab, Jira, Linear, Sentry, Azure DevOps; Bitbucket via plugin) and manages them with drag-and-drop columns and workflow automation. When you assign an agent to a task, Kandev launches it inside an isolated Git worktree via ACP or CLI passthrough, using a local process, Docker container, SSH remote, or sprites.dev executor. Agent output — code changes and conversations — appears in the integrated workspace with built-in terminal, LSP editor, git changes panel, embedded VS Code, and chat; after human review, per-repo branches become PRs. Agents can use task-agent MCP to spawn subtasks, target sibling repos, attach extra branches for multiple PRs, and message other tasks; external agents can manage Kandev itself via an external MCP over streamable HTTP or SSE. Workflows export/import as portable YAML, and tasks can be triggered on schedules or webhooks via Automations.
- A senior developer running multiple agents in parallel on a large codebase: worktree isolation prevents conflicts and offloads saturation from the local machine to remote executors.
- A team requiring human review before anything merges: review-first gates plus the integrated workspace let humans inspect agent changes before opening PRs.
- An engineer who wants to supervise agents remotely or from mobile: self-host the server and connect via Tailscale or Cloudflare Tunnel from a phone.
- A team mixing vendors: e.g., Claude Code Opus designs the plan, GitHub Copilot Sonnet implements, Codex reviews — orchestrated as a multi-step pipeline.
- Teams needing scheduled or event-driven agent work: Automations trigger tasks on cron-like schedules or webhooks with configurable concurrency.
- A developer splitting an oversized task into several PRs: sub-tasks resume from the parent task's session and can produce multiple PRs from one starting point.
What are this agent's strengths and limitations?
- True multi-provider: 20+ ACP agents (Claude Code, Codex, Copilot, Gemini CLI, Cursor, Devin, etc.) side by side, not locked to one vendor.
- Server-first architecture: the core app runs as a service accessible from any device including your phone, with SSH, Docker, and sprites.dev remote executors that offload execution beyond the local machine.
- Review-first integrated workspace: terminal, LSP editor, git changes panel, embedded VS Code, and chat in one view — addressing the scalability gap of reviewing changes in terminal TUIs.
- Worktree isolation and multi-repository tasks: concurrent agents don't conflict, and one task can span multiple repos/branches to produce several PRs.
- No telemetry, fully self-hostable: data stays on your infrastructure, and workflows migrate between Kandev installs via portable YAML.
- Non-trivial runtime requirements: building from source needs Go 1.26.0, Node.js 24, and pnpm 9.15.9; npx needs npm 7+; container executors require Docker configuration.
- Agents require their own subscriptions or credentials (Cursor Pro for Cursor; Devin, Kimi, Kiro, Qoder, Trae require separately installed CLIs), so real cost depends on the providers you choose.
- Office mode — the persistent agent-team autonomy layer — is still in progress behind a feature flag and is not yet documented as a supported feature.
- The Kubernetes executor is not implemented; it exists only on the roadmap.
- The AGPL-3.0 license imposes compliance obligations for teams embedding it in closed-source distributed services.
How do you install or deploy this agent?
macOS/Linux (Homebrew): brew install kdlbs/kandev/kandev && kandev. Windows (Scoop): scoop bucket add kandev https://github.com/kdlbs/scoop-kandev && scoop install kandev && kandev (native bundle, no Node.js needed). NPX: npx kandev@latest (npm 7+). Global npm: npm install -g kandev@latest && kandev. Nightly: npx -y kandev@nightly. From source: git clone [email protected]:kdlbs/kandev.git && cd kandev && make start, requiring Go 1.26.0, Node.js 24, pnpm 9.15.9 (pinned in mise.toml); Docker optional. Worktrees and the SQLite db live in ~/.kandev by default. Runs on macOS, Linux, and Windows (WSL or native).
How do you use this agent?
Start kandev and open the Web UI. Configure agents in agent profiles — pick an ACP package (e.g., @agentclientprotocol/claude-agent-acp) or enter any CLI command to run it as a TUI. Pull issues from GitHub/GitLab/Jira/Linear into the kanban, create tasks, assign agents, and choose an executor (local/Docker/SSH/Sprites). Agents run in isolated worktrees; review and iterate on changes in the integrated workspace (terminal, editor, git changes panel, chat), then open PRs. Configure executor profiles, secrets, custom prompts, MCP, plugins, and updates in Settings; npm/npx installs can switch Stable/Nightly in Settings > System > Updates. For remote access, follow docs/public/mobile-remote-access.md to connect via Tailscale or Cloudflare Tunnel.