KanVibe
A keyboard-first Kanban workspace that keeps AI coding agents' branch tasks, terminal sessions and status in one real-time board.
- Source repo
- rookedsysc/kanvibe
- Stars
- ★ 150
- Last updated
- today
- License
- AGPL-3.0
- Primary language
- TypeScript
- FA score
- 45/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changesCodex · Claude Code
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- Developers juggling several repository branches at once who want each branch's terminal and agent progress on a single board
- Not a fit if
- Teams unwilling to run tmux, git worktrees and gh locally
- Users who want a fully hosted web SaaS with no local install
- Anyone needing a shipped mobile app — the Flutter client must be built from source
- Source review
- 45/100 · Major gaps
What does this agent do, and when should you use it?
KanVibe is a desktop-and-self-hosted Kanban workspace that pulls AI coding work out of scattered terminal tabs. Tasks are branch-based: creating one prepares a git worktree, spawns a tmux window or zellij tab, and binds that session to the task. Terminals stream into the browser or Electron app through xterm.js over WebSocket and node-pty, with optional SSH remote terminals driven by ~/.ssh/config. Hooks from Claude Code, Gemini CLI, Codex CLI and OpenCode move tasks through TODO → PROGRESS → PENDING → REVIEW → DONE automatically, and a task reaching DONE has its branch, worktree and session deleted. It ships as a Homebrew Cask desktop app with a self-hosted Next.js 16 server, plus a Flutter mobile client you build from source.
Registering a project scans a local or remote git repository, detects existing worktree branches, and installs each agent's hook files (.claude/hooks/, .gemini/hooks/, .codex/hooks/ with hooks.json plus config.toml, and a generated .opencode/plugins/kanvibe-plugin.ts). Creating a task with a branch name runs the worktree setup, opens a tmux window or zellij tab, and links the session to the task; the terminal page renders through xterm.js + WebSocket + node-pty with six pane layouts (Single, Horizontal 2, Vertical 2, Left+Right TB, Left TB+Right, Quad) and a custom command per pane. Agents call /api/hooks/start and /api/hooks/status, which match on branchName + projectName, update status, and fire browser notifications. It also offers a Monaco-based GitHub-style diff view, an AI usage panel that reads remaining Claude/Codex/Gemini quota from each CLI's local sign-in, and pairing-code mobile mirroring.
- Developers juggling several repository branches at once who want each branch's terminal and agent progress on a single board
- Claude Code or Codex CLI users running long sessions who want status to advance to REVIEW without dragging cards
- Vim users who want h/j/k/l navigation, / search, :move progress and dd delete without leaving the keyboard
- Teams running tmux on a remote dev box and driving it from a local browser over SSH
- Solo developers who want to glance at task status and type into a task terminal from a phone
- Heavy users of multiple Claude/Codex/Gemini accounts who want remaining quota visible in one place
How do you install or deploy this agent?
The README installs the macOS desktop app from the project's own Homebrew tap:
brew install --cask rookedsysc/kanvibe/kanvibe
open -a KanVibeUpgrading and removing:
brew update
brew upgrade --cask kanvibebrew uninstall --cask kanvibe
brew untap rookedsysc/kanvibeInstall the required dependencies first:
brew install git tmux gh
gh auth loginzellij is optional:
brew install zellijThe Flutter mobile client must be built from the mobile/ directory; the README does not spell out the build command.
How do you use this agent?
Start by registering a project: click the magnifying-glass scan button on the board toolbar (between the project filter and + New Task), pick a local or remote git repository path, and hit Scan & Register — KanVibe registers the repo, detects existing worktree branches, and installs supported agent hooks. Then create a TODO with a branch name; the worktree, tmux/zellij session and terminal binding are created for you. Core shortcuts:
Cmd/Ctrl+Shift+O global quick task search
Cmd/Ctrl+Shift+P project filter dropdown
Cmd/Ctrl+Shift+I notifications dropdown
Cmd/Ctrl+0 toggle AI usage panel on task detail
Cmd+1/2/3 task detail dock: info, status/hooks, AI chatEnable Vim-style controls in Settings → Keyboard to use h/j/k/l, /, n, :move progress and dd. For mobile, open Settings → Mobile Connection → Create pairing code, then enter the desktop address, port 9736 and the 6-digit code within its 5-minute lifetime.
What are this agent's strengths and limitations?
- Branch-as-task model: creating a task provisions the worktree and tmux/zellij session, and DONE cleans all three up, so branches and terminals don't pile up
- Four documented agent integrations (Claude Code, Gemini CLI, Codex CLI, OpenCode) with distinct, honestly documented state mappings rather than a single claimed pipeline
- Deep keyboard coverage: global quick search, project filter, notification panel, numbered task-detail dock shortcuts intercepted before terminal input, and optional Vim-style board controls
- Full terminal stack: xterm.js streaming, six pane layouts with per-pane commands, SSH remote sessions reading ~/.ssh/config, and Nerd Font rendering
- AI usage panel reuses each CLI's existing local sign-in, so no extra API key is needed and KanVibe never rewrites stored credentials
- Two distribution paths (Homebrew Cask Electron desktop app and a self-hosted Next.js server) plus a buildable Flutter mobile client that mirrors panes read-only
- Heavy dependency floor: git, tmux and an authenticated gh are required, plus a Node.js/Next.js 16 runtime, Electron packaging and optional zellij
- Optimized around tmux/zellij — sessions in plain terminals or zellij are judged by transcript activity alone and may look idle while waiting for input
- Codex only reports PENDING for Bash-scoped approval waits, and project-local .codex/ hooks fire only for trusted worktree paths
- Gemini CLI has no PENDING state at all, and live subtask counts depend on OpenCode's version or are unavailable for Gemini CLI
- AGPL-3.0 with an explicit no-commercial-SaaS-distribution note, which constrains productization
- The mobile client has to be built from source, and the README gives no build steps
How does this agent compare with similar options?
The README credits workmux (a tmux workspace manager) and vibe-kanban (an AI-powered Kanban board) as inspiration, so they are the natural alternatives; KanVibe's distinction is bundling git worktrees, tmux/zellij sessions, multi-CLI hooks and a usage panel in one board.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| KanVibe This agent | 45 · Major gaps | Desktop appFree | ★ 150 | today | TypeScript | Codex · Claude Code |
| nodeterm | 65 · Some gaps | Desktop appFree | ★ 2.4k | today | TypeScript | Codex · Claude Code |
| Collie | 84 · Good | CLIFree | ★ 1.6k | today | TypeScript | — |
| Pi Subagents Multi-Agent Framework | 62 · Some gaps | Agent plugin / skillFree + model costs | ★ 136 | 1mo ago | TypeScript | — |
How does FollowAgents rate this agent?
Why each dimension lost points
README describes many high-privilege behaviors: auto-creating/deleting git worktrees and branches, spawning tmux/zellij sessions, executing remote commands over SSH, reading each CLI's stored sign-in credentials, and installing agent hooks. But the repository only supplies README, LICENSE, package.json, and CI configs; no source code is available to verify least privilege, confirmation steps, or transparency. Moving a task to DONE auto-deletes branch/worktree/session, and README does not state whether confirmation or recovery exists before deletion — deducted. Credential handling claims KanVibe never rewrites CLI-stored credentials, but no code corroborates this. Dependency security shows only a pnpm onlyBuiltDependencies allowlist, no audit or lockfile evidence. source_attribution scores 2 because README explicitly credits Inspired By projects and states AGPL licensing.
CI config shows type check, vitest, and build gates, and package.json has many qa scripts, indicating investment in self-consistency — 2. Dependency availability rests only on engines node 24.x and pnpm 10.34.5 declarations with no lockfile evidence, and depends on external binaries tmux/gh/zellij — 1. Failure messages: README only mentions the hook endpoint returning 404 with a notification; no systematic error-handling description — 1.
README clearly defines audience (developers using AI coding agents) and scenarios (multi-project, multi-agent, keyboard-first) — 2. Capability boundaries are stated (Gemini lacks PENDING, Codex is Bash-scoped, zellij sessions judged by transcript alone) — 2. Trigger precision: hook status mapping depends on CLI versions and trusted paths; README admits Codex requires manually trusting worktrees, so misfires are possible — 1. Environment fit covers only macOS (Homebrew cask, DMG); Linux only gets shortcut mentions — 1.
README information architecture is complete with prerequisites, quick start, usage flow, features, and shortcut tables — 2. Install notes are concrete (Homebrew tap, update/uninstall commands) — 2. Naming stability has no versioned API or naming conventions — 1. Examples are mostly screenshots and video, lacking textual FAQ or troubleshooting — 1. Known limitations have a dedicated section (Gemini/Codex/OpenCode differences, zellij limits) — 2. LICENSE is the full AGPL-3.0 text — 2. Version 1.5.0 exists but no CHANGELOG — 1. Maintenance responsibility points only to an individual author and contributing doc; publisher is unverified — 1.
Output usability: the product offers board, terminal, diff, and AI usage panels with concrete README descriptions — 2. Marginal value versus vibe-kanban/workmux is differentiated (hook-driven status, AI usage, mobile) — 2. Cost-benefit requires installing tmux/gh/zellij, Node 24, Electron packaging, and carries auto-deletion risk — 1.
README claims (hook endpoints, status mapping, SSH ControlMaster pool) cannot be cross-checked against source or test files; only CI config corroborates that tests exist — 1. Cross-source corroboration is partial consistency among README, package.json scripts, and CI — 1. Fact/inference separation: README distinguishes per-agent capability differences, but some performance/behavior claims (e.g., 4x CPU concurrency cap) lack support — 1.
- Moving a task to DONE auto-deletes its branch, worktree, and terminal session; README does not describe confirmation or recovery before deletion, posing data-loss risk.
- The app reads each AI CLI's stored sign-in credentials, runs their sign-in commands, and executes remote commands over SSH — a broad permission surface that needs source-level least-privilege verification.
- The repository supplies only README, LICENSE, package.json, and CI configs; source and test files are absent, so safety and reliability claims cannot be statically verified.
- Publisher identity is unverified and maintenance responsibility points to an individual author; the update path relies on a personal Homebrew tap.
- Packaging targets macOS only with limited Linux support; cross-platform users should evaluate carefully.