Cursor's Worktree Cleanup Force-Deleted My Git Branch

Cursor Easy 5-15 minutes data risk Last verified Jul 17, 2026

The fix Don't panic, and don't run anything destructive: force-deleting a branch removes the pointer, not the commits. Run git reflog, find the SHA of the branch tip, then run git branch <branch-name> <sha>. If the branch was ever pushed, git checkout -b <branch-name> origin/<branch-name> restores it instantly. Your commits are still in the repo.

Symptoms

After using Cursor 2.x background or parallel agents, one of your pre-existing branches is just gone
'git branch' no longer lists a branch you created yourself
The deleted branch had unmerged work on it
Separately, users report the agent damaging project structure while 'helping' push to git

Why it happens

WorktreeManager cleanup force-deletes matching branches

Cursor's background and parallel agents run in git worktrees. When tearing them down, the WorktreeManager cleanup logic runs 'git branch --contains' and then force-deletes ('git branch -D') all matching branches, including branches you created that were never Cursor's to manage. Reported December 2025 in forum thread 146865.

Force-delete skips the merge-safety check

'git branch -D' does not check whether the branch is merged, so unmerged work loses its ref. The commits survive, but nothing points at them anymore, which is why the branch looks gone.

How to fix it

Stop and remember: the commits still existBranch deletion removes the pointer, not the commits. Do not run any cleanup, garbage-collection, or destructive git commands right now. Your only job is to find the SHA of the branch tip and point a new branch at it.
Find the branch tip with git reflogRun 'git reflog' and scan for the last commit message you remember from that branch. The SHA next to it is the branch tip you need.
Recreate the branchRun 'git branch <branch-name> <sha>' with the SHA you found. The branch is back, with all its commits, exactly as it was.
If reflog is unclear, hunt dangling commitsRun 'git fsck --lost-found' to list dangling commits, then inspect candidates with 'git log <sha>' until you find your branch tip. Slower than reflog, but it catches cases where the reflog entries are hard to read.
If the branch was ever pushed, restore from the remoteRun 'git checkout -b <branch-name> origin/<branch-name>' and the branch is back instantly. This is also the strongest prevention: push work-in-progress branches early, and no local force-delete can hurt you.
Keep Cursor's cleanup away from branches that matterUntil the bug is fixed in your version, avoid running Cursor's parallel or background agents in repos with important unpushed local branches, or work from a separate clone. After agent sessions, run 'git worktree list' and remove leftovers yourself with 'git worktree remove' instead of letting automated cleanup decide.

How to prevent it

Push work-in-progress branches early; a pushed branch is one checkout away from restored, no matter what local cleanup does
Avoid Cursor's parallel or background agents in repos holding important unpushed branches until the WorktreeManager bug is fixed in your version
Run agent experiments from a separate clone so cleanup logic never sees your real branches
Check 'git worktree list' after agent sessions and remove leftovers manually with 'git worktree remove'

Tools that actually fix this

Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.

SimpleBackupsNo free tier (free trial)

Automated, scheduled backups of your database and storage so the AI's next confident refactor is survivable. Set it once and stop trusting an agent with your only copy.

Try SimpleBackups →

GitProtectFree for open source

Backup and recovery for your Git repositories, so a force-push or an agent's cleanup does not take your history with it. Free for open-source projects.

Try GitProtect →

Frequently asked questions

Are my commits gone when Cursor deletes a git branch?

No. Deleting a git branch, even with force-delete, removes only the branch pointer; the commits stay in the repository. Run 'git reflog' to find the SHA of the deleted branch's tip, then 'git branch <branch-name> <sha>' recreates the branch with all its work intact.

Why did Cursor delete my git branch?

Cursor's background and parallel agents run in git worktrees, and the WorktreeManager cleanup logic runs 'git branch --contains' during teardown, then force-deletes all matching branches with 'git branch -D', including branches you created yourself. Because force-delete skips the merge-safety check, even unmerged work loses its ref. The bug was reported in December 2025 in Cursor forum thread 146865.

How do I recover a deleted git branch with reflog?

Run 'git reflog' and look for the last commit message you remember from the deleted branch; the SHA beside it is the branch tip. Then run 'git branch <branch-name> <sha>' to recreate the branch. If the reflog is unclear, 'git fsck --lost-found' lists dangling commits you can inspect with 'git log <sha>' until you find the right one.

How do I stop Cursor's worktree cleanup from deleting branches?

Until the WorktreeManager bug is fixed in your Cursor version, avoid running parallel or background agents in repos with important unpushed local branches, or run them from a separate clone. Push work-in-progress branches early so any local deletion is instantly reversible from origin, and clean up leftover worktrees yourself with 'git worktree remove' after agent sessions.

Sources

The Vibe Oops briefing

One email when something ships to production that should not have. New incidents, new error guides, no filler.