fix(web): allow removing projects that still contain threads

[rohankumawat]

Summary

• Removing a project with existing threads showed a blocking warning toast ("Project is not empty") and refused to proceed, forcing users to manually delete every thread first.
• The confirmation dialog now automatically deletes all threads before removing the project.
• The dialog also clarifies that files on disk are not affected.

What changed

• Replaced the blocking toast with a cascading delete: all threads are deleted before the project is removed.
• Updated the native confirmation dialog message to include thread count (when applicable) and a reassurance that local files remain untouched.
• Added deleteThread and projectThreads to the useCallback dependency array.

Before

After

Screen.Recording.2026-04-11.at.06.47.27.mov

Test plan

• Right-click a project with threads → "Remove project" → confirm → project and threads removed
• Right-click an empty project → "Remove project" → confirm → project removed
• Cancel the confirmation → nothing happens
• Files on disk remain untouched after removal

---

Note

Medium Risk
Changes deletion behavior to automatically delete all threads before removing a project, which could cause unintended data loss or partial-failure states if thread deletions fail mid-sequence.

Overview
Removing a project from the sidebar no longer blocks when the project contains threads; it now confirms and then deletes all threads in the project before dispatching the project.delete command.

The confirmation dialog message is expanded to include the number of threads that will be deleted (when non-zero) and to clarify that files on disk are unaffected, and the callback dependencies are updated to track deleteThread and projectThreads.

^{Reviewed by Cursor Bugbot for commit 88532c1. Bugbot is set up for automated code reviews on this repo. 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: 701f2707-6ffd-48a2-8f87-d150126c1044

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.}

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

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

^{Reviewed by Cursor Bugbot for commit 88532c1. Configure here.}

[cursor]

Cascading delete triggers per-thread worktree confirmation dialogs

High Severity

The loop calls deleteThread for each thread, but deleteThread internally shows a native confirmation dialog for every thread that has an orphaned worktree (asking "Delete the worktree too?"). After the user already confirmed the project removal, they can be bombarded with additional unexpected dialogs — one per qualifying thread. This also contradicts the parent confirmation message claiming "Your files on disk will not be affected," since deleteThread can actually remove worktrees from disk if the user clicks through those prompts.

 

^{Reviewed by Cursor Bugbot for commit 88532c1. Configure here.}

[cursor]

Thread deletion before project validation risks data loss

High Severity

All threads are irreversibly deleted before validating that the project API is available and before attempting the project deletion command. If readEnvironmentApi returns null or dispatchCommand throws, the catch block shows a "Failed to remove project" toast — but the threads are already gone. This is a non-atomic cascading delete that can silently cause data loss while leaving the project intact.

Additional Locations (1)

• apps/web/src/components/Sidebar.tsx#L1346-L1349

 

^{Reviewed by Cursor Bugbot for commit 88532c1. Configure here.}

[macroscopeapp]

Approvability

Verdict: Needs human review

This PR changes project deletion from blocking (when threads exist) to cascading deletion of all threads. Two high-severity unresolved review comments identify potential data loss scenarios and UX issues with the non-atomic delete implementation. The behavioral change and substantive concerns warrant human review.

^{You can customize Macroscope's approvability policy. Learn more.}