Changes since v0.1.8

This branch preserves the v0.1.8 UI while cherry-picking performance, stability, and quality-of-life improvements from upstream.

Logging overhaul (file-based log storage)

• Moved execution process logs from SQLite to file-based storage, eliminating database bloat and improving streaming performance for long-running tasks (blog post, PR #1969)

Backend performance & stability

• Optimized workspace process lookup — replaced correlated subquery with ROW_NUMBER window function, eliminating >1s query times
• Throttled SQLite workspace timestamp updates — stopped spamming UPDATE workspaces SET updated_at on every event
• Preserved worktree path across cleanup — fixes Claude Code losing sessions after cleanup because path was recomputed from a possibly-renamed workspace title (adds worktree_deleted DB field)
• Fixed duplicate workspace prompt recovery — reads first prompt from executor_action chain instead of relying only on coding_agent_turns
• Clean untracked files on retry/reset — previously left files behind that could confuse LLMs or get accidentally committed
• Remounted execution process provider on workspace/session switch — fixes stale logs showing for the wrong workspace

Log streaming & deduplication

• Deduplicated consecutive patches in log streaming — avoids sending redundant JSON patches over the websocket when streaming historical normalized logs (touches all executor normalizers + container streaming logic)

Auth & token refresh

• Refresh token reliability overhaul — proactive JWT-based token expiry checking with 20s leeway instead of relying on 401 responses; makes token refresh timeout errors non-retryable to prevent refresh token reuse (backend + frontend + remote-frontend)

Trivial upstream fixes

• Conversation history corruption stopgap — fixes incomplete entries in large conversations due to websocket lag
• Handle signature_delta in Claude streaming — suppresses spurious "Mismatched content types" warning from Claude API thinking events
• Set correct default context windows for 1M models
• Bump Claude Sonnet model to 4.6
• Fix migration failure for long task titles — truncates to 255 chars to match Postgres VARCHAR constraint
• Delete old binary versions from cache on startup — prevents unbounded disk growth in ~/.vibe-kanban/bin/
• Logging noise reduction — suppress codex_core tracing, noisy PR monitor errors, diff stream repo-not-found warnings, cache build for non-existent repo paths, duplicate model name log entries, and missing Linux notification daemon errors

Frontend improvements

• Frontend performance cherry-picks — targeted performance improvements for streaming/rendering without changing the v0.1.8 UI layout
• Resized new card/edit card dialog — enlarged the task form dialog so descriptions are easier to read and write
• Fixed fullscreen scroll — prevented scroll wheel from scrolling the entire UI off-screen in fullscreen mode

MCP server enhancements

• Subtask support — the MCP server now supports creating and managing subtasks parented by workspace attempts

---

Get 10X more out of Claude Code, Gemini CLI, Codex, Amp and other coding agents...

We're hiring!

Overview

AI coding agents are increasingly writing the world's code and human engineers now spend the majority of their time planning, reviewing, and orchestrating tasks. Vibe Kanban streamlines this process, enabling you to:

• Easily switch between different coding agents
• Orchestrate the execution of multiple coding agents in parallel or in sequence
• Quickly review work and start dev servers
• Track the status of tasks that your coding agents are working on
• Centralise configuration of coding agent MCP configs
• Open projects remotely via SSH when running Vibe Kanban on a remote server

You can watch a video overview here.

Installation

Make sure you have authenticated with your favourite coding agent. A full list of supported coding agents can be found in the docs. Then in your terminal run:

npx vibe-kanban

Documentation

Please head to the website for the latest documentation and user guides.

Support

We use GitHub Discussions for feature requests. Please open a discussion to create a feature request. For bugs please open an issue on this repo.

Contributing

We would prefer that ideas and changes are first raised with the core team via GitHub Discussions or Discord, where we can discuss implementation details and alignment with the existing roadmap. Please do not open PRs without first discussing your proposal with the team.

Development

Prerequisites

• Rust (latest stable)
• Node.js (>=18)
• pnpm (>=8)

Additional development tools:

cargo install cargo-watch
cargo install sqlx-cli

Install dependencies:

pnpm i

Running the dev server

pnpm run dev

This will start the backend. A blank DB will be copied from the dev_assets_seed folder.

Building the frontend

To build just the frontend:

cd frontend
pnpm build

Build from source (macOS)

1. Run ./local-build.sh
2. Test with cd npx-cli && node bin/cli.js

Environment Variables

The following environment variables can be configured at build time or runtime:

Variable	Type	Default	Description
POSTHOG_API_KEY	Build-time	Empty	PostHog analytics API key (disables analytics if empty)
POSTHOG_API_ENDPOINT	Build-time	Empty	PostHog analytics endpoint (disables analytics if empty)
PORT	Runtime	Auto-assign	Production: Server port. Dev: Frontend port (backend uses PORT+1)
BACKEND_PORT	Runtime	0 (auto-assign)	Backend server port (dev mode only, overrides PORT+1)
FRONTEND_PORT	Runtime	3000	Frontend dev server port (dev mode only, overrides PORT)
HOST	Runtime	127.0.0.1	Backend server host
MCP_HOST	Runtime	Value of HOST	MCP server connection host (use 127.0.0.1 when HOST=0.0.0.0 on Windows)
MCP_PORT	Runtime	Value of BACKEND_PORT	MCP server connection port
DISABLE_WORKTREE_CLEANUP	Runtime	Not set	Disable all git worktree cleanup including orphan and expired workspace cleanup (for debugging)
VK_ALLOWED_ORIGINS	Runtime	Not set	Comma-separated list of origins that are allowed to make backend API requests (e.g., https://my-vibekanban-frontend.com)

Build-time variables must be set when running pnpm run build. Runtime variables are read when the application starts.

Self-Hosting with a Reverse Proxy or Custom Domain

When running Vibe Kanban behind a reverse proxy (e.g., nginx, Caddy, Traefik) or on a custom domain, you must set the VK_ALLOWED_ORIGINS environment variable. Without this, the browser's Origin header won't match the backend's expected host, and API requests will be rejected with a 403 Forbidden error.

Set it to the full origin URL(s) where your frontend is accessible:

# Single origin
VK_ALLOWED_ORIGINS=https://vk.example.com

# Multiple origins (comma-separated)
VK_ALLOWED_ORIGINS=https://vk.example.com,https://vk-staging.example.com

Remote Deployment

When running Vibe Kanban on a remote server (e.g., via systemctl, Docker, or cloud hosting), you can configure your editor to open projects via SSH:

1. Access via tunnel: Use Cloudflare Tunnel, ngrok, or similar to expose the web UI
2. Configure remote SSH in Settings → Editor Integration:
   • Set Remote SSH Host to your server hostname or IP
   • Set Remote SSH User to your SSH username (optional)
3. Prerequisites:
   • SSH access from your local machine to the remote server
   • SSH keys configured (passwordless authentication)
   • VSCode Remote-SSH extension

When configured, the "Open in VSCode" buttons will generate URLs like vscode://vscode-remote/ssh-remote+user@host/path that open your local editor and connect to the remote server.

See the documentation for detailed setup instructions.