Prior to this update, the worktree workflow was in a stable spot (bringing over changes cleanly, undoing changes cleanly, visual representation of being in worktree) and now the UX is muddied and the application of worktrees is not stable. All I want at the core is an easy visualized way to do true parallel work. My previous workflow was to open up an agent, choose worktree mode and then have it do some task. I would come back to it later and apply changes to the main repo and test. If I needed further adjustments, I would undo the applied changes, give it xyz instructions, and come back later and rinse and repeat.
Regarding new update:
I always start out with plan mode. I tried using /worktree skill in plan mode and nothing happened. After the plan was built out, I then told it to build the plan to a worktree with /worktree in agent mode.
It started building out the plan on a worktree, but when I opened the worktree repo itself to inspect it, cursor had not respected my worktree.json at all, which defines copying over dotfiles, running setup, etc. The worktree repo had none of this. As such, the agent failed when trying to do certain task work once it was operating in the context of the worktree, since these post-setup changes were not applied.
After completing some work, I instructed the agent to copy over worktree files and it takes much longer than it used to as it goes through the agent and all subtasks to do this. This also in and of itself consumes tokens. Previously, bringing over changes was handled quickly and simply through an “Apply Changes” button.
Now with the changes applied to the main repo, there is no quick way to unapply the worktree changes. I have to deal with discarding the changes manually or again telling the agent to discard, which takes time and tokens.
There is not an easy way to identify work that exists on a worktree now because it’s buried in chat. Previously, you could identify a worktree agent by the worktree icon. Also, you could click on the agent to get the specific worktree name.
Also, your chat history is now polluted with messages that deal with setup/copy over/discard related things, instead of the chat being focused on the task you are actually trying to accomplish.
In addition, this whole workflow also makes it easy for the agent to lose context of where the changes should happen. I have to explicitly tell the agent to make whatever change I’m suggesting on the worktree for every message, otherwise it was sometimes making its changes in the main repo.
As outlined above, there are many UX frustrations with the new worktree changes.
