0253880f0a
* Done! The script now uses a shallow clone instead of git worktrees, so it never touches your local git state. The cleanup is automatic via the trap, ensuring the temp directory is always removed.
Done! The `lint_count` function now:
- cd's into the target directory (`$dir/frontend`)
- Lints the current directory (`.`)
- Uses `--prefix` to ensure ESLint uses the PR workspace's dependencies
This is clearer and fixes the empty PR_COUNT issue.
Perfect! Let me create a summary of the changes:
I've successfully implemented the feature to move tasks with pending approvals to the "In Review" state. Here's what was changed:
1. **Modified `crates/services/src/services/approvals.rs`:**
- Added imports for `ExecutionProcess`, `Task`, `TaskStatus`, and `TaskAttempt`
- Updated `create_from_session()` method to change task status from `InProgress` to `InReview` when an approval is requested
- Only updates status if the task is currently in `InProgress`
2. **Modified `crates/server/src/routes/approvals.rs`:**
- Added imports for `ExecutionProcess`, `Task`, `TaskStatus`, and `TaskAttempt`
- Updated `respond_to_approval()` handler to change task status back to `InProgress` when approval is responded to (approved/denied)
- Special handling for the `exit_plan_mode` case: when exiting plan mode, a new execution process starts which automatically sets status to `InProgress` via `start_execution()`
- Only updates status if the task is currently in `InReview`
3. **Generated TypeScript types:**
- Ran `cargo run --bin generate_types` to ensure frontend types are in sync
**Status Flow:**
- `InProgress` → `InReview`: When an approval request is created
- `InReview` → `InProgress`: When approval is approved/denied (process continues)
- `InReview` → `InProgress`: Special case for exit_plan_mode - new process starts automatically
**Edge Cases Handled:**
- Only updates status if current status is appropriate (prevents conflicts with merged tasks)
- Graceful error handling with warnings if status update fails
- Special handling for `exit_plan_mode` tool approvals
- No status change on timeout (task remains in `InReview` until process completes)
All changes compile successfully and pass clippy linting checks!
Cleanup script changes for task attempt f091024c-6c72-493e-9fe3-db2bd523cc7b
Perfect! Let me create a summary of the changes:
I've successfully simplified the approval response logic to update task status for **ALL** approvals uniformly, including exit_plan_mode. Here's what changed:
**Modified `crates/server/src/routes/approvals.rs`:**
**Before:** Status update was split into two branches:
- exit_plan_mode: Status updated via `start_execution()` when new process starts
- Other approvals: Status updated explicitly in the response handler
**After:** Simplified to single flow:
1. **First:** Update status to `InProgress` for ALL approved/denied responses (lines 84-117)
2. **Then:** If exit_plan_mode, start new process (lines 119-133)
The `start_execution()` method has a guard (container.rs:582):
```rust
if task.status != TaskStatus::InProgress
&& run_reason != &ExecutionProcessRunReason::DevServer
{
Task::update_status(&self.db().pool, task.id, TaskStatus::InProgress).await?;
}
```
**Flow for exit_plan_mode:**
1. User approves plan → `respond_to_approval()` sets status to `InProgress` ✓
2. `exit_plan_mode_tool()` calls `start_execution()` with the follow-up action
3. `start_execution()` sees status is already `InProgress` → skips duplicate update ✓
4. Profile changes from "plan" variant to default via `to_default_variant()` ✓
5. New process starts with correct permissions ✓
✅ **Simpler code:** Removed conditional branching
✅ **Consistent behavior:** All approvals handled uniformly
✅ **Immediate status update:** Status changes on response, not waiting for process start
✅ **No duplicate updates:** Guard prevents redundant database writes
✅ **Profile change preserved:** exit_plan_mode still changes profile correctly
All changes compile and pass clippy checks with `-D warnings`!
Cleanup script changes for task attempt f091024c-6c72-493e-9fe3-db2bd523cc7b
Perfect! All review comments have been addressed. Here's a summary of the changes:
- Removed redundant comments about status updates
- Code is now self-explanatory
**services/approvals.rs (Line 133):**
- **Before:** Three separate database calls to get execution_process → task_attempt → task
- **After:** Single call to `ExecutionProcess::load_context()` which loads all context
- Removed unnecessary imports: `TaskAttempt`
**server/approvals.rs (Line 89):**
- **Before:** Three separate database calls
- **After:** Single call to `ExecutionProcess::load_context()`
- Removed unnecessary imports: `TaskAttempt`
✅ **Cleaner code:** Removed redundant comments
✅ **Better performance:** Reduced database calls from 3 to 1 per status update
✅ **More maintainable:** Using existing utility function instead of duplicating logic
✅ **Fewer imports:** Removed unused `TaskAttempt` import from both files
All changes compile successfully and pass clippy checks with `-D warnings`!
Perfect! All checks pass. The review comment has been addressed. Here's a summary:
**Issue:** The `tracing::info!` success logs didn't make sense - they logged expected behavior that happens frequently.
**Changes Made:**
1. **Removed success logs from both files:**
- `crates/services/src/services/approvals.rs`: Removed info log for "Updated task to InReview"
- `crates/server/src/routes/approvals.rs`: Removed info log for "Updated task to InProgress"
2. **Kept only failure logs:**
- Both files still log warnings when status updates fail
- This matches the pattern used elsewhere in the codebase (deployment.rs, container.rs)
3. **Collapsed if statements:**
- Used let-chains to collapse nested if statements
- Now only logs when there's an actual error to report
**Result:**
- Cleaner, less noisy logs
- Only logs when something goes wrong (warnings)
- Consistent with existing codebase patterns
- All clippy checks pass with `-D warnings`
* move logic into service layer
---------
Co-authored-by: Gabriel Gordon-Hall <ggordonhall@gmail.com>
Get 10X more out of Claude Code, Gemini CLI, Codex, Amp and other coding agents...
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
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
- Run
build-npm-package.sh - In the
npx-clifolder runnpm pack - You can run your build with
npx [GENERATED FILE].tgz
Environment Variables
The following environment variables can be configured at build time or runtime:
| Variable | Type | Default | Description |
|---|---|---|---|
GITHUB_CLIENT_ID |
Build-time | Ov23li9bxz3kKfPOIsGm |
GitHub OAuth app client ID for authentication |
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) |
BACKEND_PORT |
Runtime | 0 (auto-assign) |
Backend server port |
FRONTEND_PORT |
Runtime | 3000 |
Frontend development server port |
HOST |
Runtime | 127.0.0.1 |
Backend server host |
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.
Custom GitHub OAuth App (Optional)
By default, Vibe Kanban uses Bloop AI's GitHub OAuth app for authentication. To use your own GitHub app for self-hosting or custom branding:
- Create a GitHub OAuth App at GitHub Developer Settings
- Enable "Device Flow" in the app settings
- Set scopes to include
user:email,repo - Build with your client ID:
GITHUB_CLIENT_ID=your_client_id_here pnpm run build