The apply/review card and buttons only show the latest update in the worktree to apply.
Steps to Reproduce
Do a parallel generation, dont select or apply any, then ask them all to update something.
Expected Behavior
The apply/review would show the actual worktree differences, not just the latest update. Perhaps use a “keep” button if you want the user to select to keep the latest change to the worktree, but thats not what the apply button says, it says apply to your main wd.
Operating System
Windows 10/11
Current Cursor Version (Menu → About Cursor → Copy)
Now when I want to “try” the worktree, it only gives me the option to apply the latest change from my perspective, not the actual diff between the workspace and the worktree. Review only shows me the +19/-16 diff.
This is a known issue with the review card in parallel worktrees - when you make several update requests in a row, the card shows only the last change instead of the full diff between the worktree and the main branch.
You correctly found the temporary workaround using Apply → Undo to see the full diff. I’ll pass this to the team for a fix.
Could you also share the Request ID from the chat context menu (top right → Copy Request ID)?
There’s also a “bug”, not necessarily an actual bug, but a bad consequence if you do the following:
hit apply on one of the worktrees, lets call it worktree 1
revert your changes to your project in git
hit apply on another one of the worktrees
now when you go back to worktree 1, it’s no longer connected to the worktree, but still thinks its local and applied, and there does not appear to be anyway to switch it back to the worktree. So if you send a new message, it thinks your current project has the existing already, and only applies a latest diff to it after the new message. The only way at this point to manually recover the worktree changes is to go to the actual worktree directory and move those files or diff and apply to main directory, and then you have to apply the 2nd diff
I’d recommend letting you switch it back to the worktree / revert the “applied” status as you manually unapplied it by git reverting. The unapply feature doesn’t always work properly so I tend to just revert to make sure I’m back at origin HEAD, and this “bug” happens when i forget to hit unapply first.
It breaks the parallel generation entirely as I can no longer continue it as it will only ever try to apply to local. Here’s a request id where that happened to two of the worktrees: 661c9937-c277-47ba-84e2-9c24eae552e3
Heres what the worktree looks like and you can see theres no worktree icon anymore, nor any way to apply the changes.
The worktrees in general need a few bug fixes like the above, the parallel generations are more of a premium feature that cost a lot of money when you’re using expensive models especially, so to encounter bugs like this that do things like make the chat unable to continue for some branches or make some worktrees unapplyable is very frustrating as you “waste” a decent amount of money. Thankfully, the responses and worktrees are still there so I can still recover what I paid for manually, but this is a dangerous feature to have mess up when the cost for using it can easily be tens of dollars depending on project size and task.
How the cloud agents work is much better, rather than an apply or unapply its a checkout of the branch and then a checkout of master to revert, but cloud agents tend to be much more expensive for me (already a high usage user) as I believe it uses a lot more context so I don’t use that feature as much as parallel generation on the worktrees.
