af8298744d
* The fix is complete. Here's a summary of the changes: **Problem**: Clicking "View Full Logs" button opened the logs panel but showed "Select a process to view logs" error because the process ID wasn't being passed to the logs panel context. **Root cause**: In `PreviewControlsContainer.tsx`, when `onViewProcessInPanel` was provided but `targetId` was falsy, the fallback path only switched the panel mode without setting which process to display. **Solution**: Modified `PreviewControlsContainer.tsx` to use `viewProcessInPanel` directly from the `LogsPanelContext` instead of relying on the prop. This ensures the process ID is always properly set when switching to the logs panel. **Changes made**: 1. `frontend/src/components/ui-new/containers/PreviewControlsContainer.tsx`: - Added import for `useLogsPanel` hook - Removed `onViewProcessInPanel` prop from interface - Use `viewProcessInPanel` from context directly - Updated `handleViewFullLogs` to call the context function 2. `frontend/src/components/ui-new/containers/RightSidebar.tsx`: - Removed unused `useLogsPanel` import - Removed `viewProcessInPanel` from destructuring - Removed `onViewProcessInPanel` prop from `PreviewControlsContainer` usage * All checks pass. The diagnostic logging is now in place. Here's a summary: ## Diagnostic Logging Added **Frontend** (`frontend/src/hooks/useLogStream.ts`): - Logs when WebSocket connection is opened with process ID - Logs successful connection - Logs errors with process ID - Logs close events with code and reason **Backend** (`crates/server/src/routes/execution_processes.rs`): - Logs when checking stream for an exec_id - Logs warning if no stream found - Logs when stream is found and WebSocket is being upgraded **Backend** (`crates/services/src/services/container.rs`): - Logs when looking up msg_store - Logs if in-memory store is found - Logs if falling back to DB - Logs DB record count or warnings if no logs found **Backend** (`crates/local-deployment/src/container.rs`): - Logs when creating a new store for a process - Logs when store is inserted into the map with map size ## Next Steps Run `pnpm run dev:qa`, reproduce the issue by: 1. Starting a dev server in a workspace 2. Clicking "View Full Logs" Then share the logs from: - **Browser console** (look for `[useLogStream]` messages) - **Backend terminal** (look for `stream_raw_logs`, `track_child_msgs_in_store` messages) * Cleanup script changes for workspace 5963230a-5419-40d6-89e9-b26519d38291 * The fix is complete. The issue was that `handleViewFullLogs` accepted an optional `processId` parameter, but when used as a button `onClick` handler, it received the click event instead. Since the click event object is truthy, the `??` operator didn't fall through to `activeProcess?.id`, causing the event object to be passed to `viewProcessInPanel()`. The fix removes the parameter so the function always uses `activeProcess?.id` directly. You can now test by running `pnpm run dev:qa` and clicking "View Full Logs" - it should correctly open the logs panel with the dev server logs. * All diagnostic logs have been removed. The fix is complete and all checks pass.
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
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)
- Run
./local-build.sh - 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_ORPHAN_CLEANUP |
Runtime | Not set | Disable git worktree cleanup (for debugging) |
Build-time variables must be set when running pnpm run build. Runtime variables are read when the application starts.
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:
- Access via tunnel: Use Cloudflare Tunnel, ngrok, or similar to expose the web UI
- 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)
- 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.