Thanks for reporting — can you tell us how you were using the worktree? Were you running multiple models in parallel, or did you manually select “Worktree” from the environment selector?
When you say the worktree was “lost”, did you see actual changes disappear, or was it more that the indicator/UI switched away from worktree mode?
I tested this on 2.6 but I wasn’t able to reproduce it. It’s probably a rare thing to bump up against your request limit, but if you experience this behavior again on 2.6 (you can download it here if you haven’t auto-updated) please let us know!
Same issue here. After switching some models and got some connection issue somehow, the working tree directory is lost. While trying to locate the working tree, there hints "/Users/myname/.cursor/worktrees/myproject/yny" does not exist. Actually this directory `/Users/myname/.cursor/worktrees/myproject/`is empty. But Cursor is still trying to use the working tree under this one. So Cursor failed to apply code changes due to Worktree not found. Trying to reload project wordspace or restart cursor following the Agent’s instruction doesn’t help at all.
Hi! We’ve recently made significant changes to how Worktrees function in Cursor.
It would be great if you could try the updated version and let us know whether you’re still experiencing issues with worktrees being “lost” when the model switches.
While the new implementation may not have quite as polished a UX yet, we rebuilt this from the ground up to create a more stable foundation that we can iterate on more effectively.
I just hit something similar to this thread on Version: 3.0.16 (Universal). I had two agents working in two different worktrees and completed their assignments. When I gave follow-up prompts to make some adjustments to their work, both of their running vite instances stopped and the git worktrees were reset. After some scrambling the agents sort of came to the same conclusion.
”I hit a real workspace blocker before making the UI change.
The [redacted] worktree at /Users/[redacted]/.cursor/worktrees/[redacted]is currently in an unexpected state: the directory only contains .git, .gitignore, and README.md, and git status shows essentially the whole repo as deleted from that worktree. That does not match the earlier implementation state we were building on.”
Because the work was uncommitted at the time, I ultimately had to have the agents re-implement it. I did not really explicitly switch models though (gpt-5.4-fast), but I do have a sub-agent that sometimes runs composer.
Just to follow-up again this morning. I’m finding that the files in Worktrees are being regularly wiped out but it’s unclear to me why. I’ve checked the agents’ command history and they did not seem to do anything that would cause this to happen. Here’s an example where I popped into the worktree to find that our entire repo is marked for deletion. The worktree is still pointed at the branch it was intended for, but every file has essentially been deleted.
There is a periodic cleanup (every 6h by default) that deletes the oldest cursor-managed, taskScoped worktrees once you exceed the per-workspace count (20) or global size (50 GB) thresholds. Worktrees that are less than 10 minutes old are excluded. This is documented here (and configurable).
