Tells you a lot about how they internally only work with one local main worktree and then everything is cloud. Incredible that 8 days after releasing these changes to worktrees they just brick it all for anyone relying on that workflow.
Why aren’t any of these /worktree commands available in Glass?
>Why aren’t any of these /worktree commands available in Glass?
They don’t work well in Glass so they’re disabled. Also, we’re working on a better native worktree feature in Glass.
this version is a significant downgrade for me.
My organization is trying to force me to stop using Cursor in favor of Claude. My biggest argument for staying with cursor is the availability of multiple agent/model providers and WAS the ability to use multiple models
That latter option is now non functional. I’m sure you’ll fix it but the slash command workflow over the interface feels less intuitive and the fact that it actually doesn’t work on release makes it hard for me to continue to argue for a tool that basically everyone else in my organization already feels is inferior to claude.
Furthermore I was asked to give a presentation on the benefits of cursor using my workflows and strategies which I can’t replicate with Claude and now I also can’t replicate it with cursor. I have less than a week for this to start working again and today I’m spending my time looking for an alternative because this just doesn’t work.
Wondering what everyone else thinks of this one - Merge editor view & chat as optional configuration - #5 by hmeng
This new approach to worktrees is a big downgrade in my experience. The agent doesn’t reliably apply changes in the work tree it creates. It burns tokens to set it up. It’s much less clear and deterministic. I have greatly preferred the UI where I could manually choose to enter a work tree mode and then apply fixes via the UI. Very disappointed.
Hey, we just had some downtime in production due to the new agentic worktree workflow.
When merging a worktree into the main repo that one of our developers is working on, the agent randomly decided to create a commit which deployed some extremely unfinished work to production.
The previous way WorkTree worked, where the merge was done deterministically, was safe.
best of n doesn’t work with plan mode. often, plans are the highest value i get out of multiple attempts at the same problem. synthesizing them together is great. as a work around i guess i can have an agent build out a MD file and make sure it doesn’t mess with any of the code, but this sucks way more than just having the UI option.
There have been a few updates released since 3.0, but the worktree functionality is still largely broken and unusable.
The models are still stumbling around confused trying to initialize the worktree and being blocked by the sandbox.
I tried the worktree functionality in the new “Agents window” and that is unusable as well. There is no option to apply the worktree changes to the main branch to test the changes locally. You can only commit, push, or make a PR. As if you’re working on the main branch.
I thought this would be fixed by now, but no, the whole thing is still broken and nobody at Cursor cares.
Having spent another 10 hours coding with Cursor 3, I wanted to re-emphasise Piotr’s point.
Previously, you could set multiple agents running on different worktrees for different features. Once the features were complete, you could merge each, one by one, into the current working branch so that you could check it, and if happy create a commit (or branch and commit). This was incredibly efficient.
Now if we create work in a worktree, what exactly is the expected workflow for seeing this on main? Are we supposed to check out the new branch? This seems old school and adds extra steps, and importantly makes it impossible to work on multiple features in one repo in parallel.
I think this is a great update and I prefer this workflow over the Cursor 2 approach, which was useless in our methodology. However, the release and docs are misleading, because if you are using Cursor Agents UI/Glass it’s a totally different implementation which doesn’t have /worktree, /best-of-n nor respects worktrees.json as documented. So essentially all 3 features are broken in Glass. I’ve actually gone full glass this week, skipping the IDE entirely, and of course there are some understandable bugs and nuances, but this one is really blocking me from working smoothly. Please prioritize it.
@Will_Taylor You are right that the Cursor 2’s approach to worktrees was to parallelize fully independent contexts and code and then decide what to apply to main. Cursors 3’s approach to worktrees is PR-oriented. So what you should do is merge each session/task/feature individually to master with its own PR.
This fits much better with PR-based development (single long-lived branch + short-lived feature/bug branches), which currently is the most popular workflow and has won largely over git flow (multiple long living stable/dev/release branches) or trunk-based development (commits directly to master). All the AI tools around agent automations, most importantly PR reviewers (like Cursor Bugbot) also rely largely on the 1 feature-1 PR logic.
So, I’d say they got it right, or at least they fit the majority now. Also note how the Glass UI is single agent session and single PR oriented to simplify everything. So they have to make worktrees usage consistent with this necessarily.
I’ve just taken some significant time to upgrade to Cursor 3 again, to see if I still have issues. I immediately started having issues again. This time I’ve “documented” them as bug reports:
- New /worktree waits for approval due to sandbox
- New /worktree command requires approval for setup steps
- New /worktree unnecessarily clutters agent output
- /apply-worktree requires approval
- Glass: no shortcut to switch to worktree mode
- No "/apply-worktree" in new Agent Window
I could probably find more issues by actually trying to continue, but I now need to get some actual work done, so will move back to Cursor 2 again instead of trying to fight Cursor 3…
I can much more efficiently get my work done in Cursor 2 using many parallel agents. I do want to say though that I’d really like to work with the new Agent Window. It just isn’t compatible with actual parallel work with worktrees in my experience, making it ultimately useless / far inferior to Cursor 2.
Hey everyone,
I just wanted to drop a quick note to let you all know that we’re listening to your feedback, and to clarify a few things:
-
We understand that some of you loved this feature, and we’re sorry that it went away. We removed it because usage was very low relative to the complexity it added, but we know that doesn’t make it less frustrating if you relied on it. Moreover, the IDE interface did not suit this kind of feature as well as the new Agents Window does.
-
The
/worktreeskill has a known issue where it doesn’t work in Plan Mode. We’re fixing that. -
The new implementation does unlock some things that weren’t possible before, such as multi-root workspace support for both
/worktreeand/best-of-n. -
One issue we’re aware of is that agents can sometimes forget they’re working in a worktree during longer sessions. Some of this comes down to models’ ability to follow instructions, and we’re investigating training future versions of our own model to be better here.
We’re close to launching native worktree support in the Agent Window. Worktrees are powerful for parallel agent workflows, and the Agent Window is the right place to build that well. We’ll be looking for your feedback when it ships!