Implement approved plans in new worktrees

[Mitch515]

What Changed

• add a UI flow for taking an approved plan and starting implementation in a new worktree
• wire the approved-plan action into the existing chat and plan UI flow
• add supporting behavior needed for the new-worktree implementation path

Why

• approving a plan should lead directly into isolated implementation without requiring manual worktree setup first
• the plan UI becomes more useful when it can hand off into the next concrete step

UI Changes

• screenshots and video are attached in the PR asset comment

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes, if applicable

Note

Implement approved plans in new git worktrees from ChatView

• Adds an 'Implement in new worktree' menu item to the plan actions menu in ChatView.tsx, which creates a new git worktree from the active branch and starts an implementation thread scoped to that worktree.
• Introduces startImplementationThread to centralize thread creation, optional setup-script execution, first-turn dispatch, snapshot sync, and navigation for both new-thread and new-worktree flows.
• When worktree creation succeeds but thread initialization fails, an AlertDialog surfaces rollback options: keep or delete the newly created worktree.
• Refactors runProjectScript to accept a target thread/project/worktree context, enabling setup scripts to run in the correct terminal group for non-active threads.
• Adds browser tests covering menu item visibility, successful worktree creation flow, and rollback UI on thread-start failure.

^{Macroscope summarized b74be50.}

---

Note

Medium Risk
Adds a new plan-to-implementation path that creates/deletes git worktrees and starts new threads, plus refactors terminal/script execution targeting; failures could leave inconsistent thread/worktree state if edge cases are missed.

Overview
Enables implementing an approved plan directly into a new git worktree, adding an Implement in new worktree action alongside the existing new-thread action and wiring it to gitCreateWorktree + new implementation thread creation.

Refactors implementation thread startup into a shared startImplementationThread helper and expands runProjectScript to support targeting a specific thread/project/worktree (used to run optional setup scripts in the correct terminal group).

Adds failure handling when worktree creation succeeds but thread startup/setup fails: an AlertDialog offers keep vs delete the created worktree (with git query invalidation on delete), and browser tests cover menu visibility, successful worktree start, and rollback UI; MSW websocket replies now surface mock RPC errors instead of crashing.

^{Written by Cursor Bugbot for commit b74be50. This will update automatically on new commits. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 2e3b8513-f27b-406a-a4d1-2f48aefbab17

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[Mitch515]

Assets for review:

Implementation actions screenshot:

Muted video:

• plan-implementation-worktrees.mp4

[cursor]

Silent early returns bypass throwOnError contract

Medium Severity

runProjectScript has multiple early return paths (guard conditions at lines 1410 and 1411–1413) that silently resolve even when throwOnError is true. In startImplementationThread, runWorktreeSetupScript is called with throwOnError: true, expecting an error to propagate if the script fails to execute. If any guard condition triggers (e.g., a timing issue with isServerThread or missing api), runProjectScript returns undefined instead of throwing, so startImplementationThread proceeds to dispatch thread.turn.start as if the setup succeeded — creating a thread without its setup script and without any error feedback.

Additional Locations (1)

• apps/web/src/components/ChatView.tsx#L1198-L1206

 

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Unstable useMutation return defeats useCallback memoization

Low Severity

createWorktreeFromBaseBranch wraps createWorktreeMutation.mutateAsync in a useCallback with [createWorktreeMutation] as a dependency. Since useMutation returns a new object reference on each render, this useCallback recreates every render, providing no memoization benefit. This cascades to onImplementPlanInNewWorktree, which lists createWorktreeFromBaseBranch in its own dependency array, causing it to also recreate every render.