Cursor replaced most of its Git WorkTrees implementation with Markdown-based commands built from skills and subagents.
2
The new approach is easier to maintain and supports multi-repository workflows, mid-chat worktree creation, and richer comparison of model outputs.
3
Prompt-based worktrees can fail when models forget their assigned checkout, so Cursor is using evals, system reminders, and reinforcement learning to improve them.
Summary
David Gomes explains how Cursor replaced a large Git worktrees feature with commands whose behavior is defined mostly in Markdown. The original implementation handled worktree creation, setup scripts, agent isolation, judging, harness changes, and cleanup. Cursor removed about 15,000 lines of code and rebuilt the workflow with skills, subagents, and slash commands. The new version lets users start isolated work from a chat, run the same task across different models, compare their results, and combine parts of multiple implementations. It also works across multiple repositories. The tradeoff is that isolation is now enforced through instructions rather than by preventing file access in code. Models can forget their worktree, especially during long sessions. Gomes describes evals that check both the assigned worktree and the primary checkout, then explains how Cursor plans to use those results for prompt changes and Composer training. Cursor is also building a more native worktrees experience for its newer agent-focused interface and exploring parallelization methods that do not depend on Git.
Git worktrees let Cursor run parallel agents in isolated checkouts
Gomes describes Git worktrees as separate checkouts of a repository. Each agent can work on its own checkout without changing the primary one, and its commands, linting, and other actions stay scoped there. Cursor can display grids of agents, open pull requests from individual worktrees, and let users run the same prompt against different models. The feature also supports visual comparison for frontend work, so a user can inspect several implementations before choosing one. Cursor shipped this workflow around October of the previous year alongside Cursor 2.0.
The original feature carried code for isolation, setup, judging, and cleanup
The first implementation had to create and manage worktrees, pass them into the agent as context, and stop agents from escaping their assigned checkout. It also supported user-configured setup scripts, model judging, harness changes, and system reminders. Cleanup was another problem because users could create hundreds of worktrees and consume large amounts of disk space. Gomes says Cursor later opened a pull request that deleted around 15,000 lines of code. The replacement was intended to provide nearly the same feature with much less maintenance.
Skills and subagents can recreate worktree and best-of-N workflows
Cursor combined two existing primitives, agent skills and subagents. A worktree command tells the model how to create a checkout, run the user's setup scripts, and remain there while completing a task. A best-of-N command asks a parent agent to create subagents for different models, give each one a separate worktree, wait for all of them, and compare the results. The best-of-N skill is about 40 lines of Markdown, while Gomes says the previous version was roughly 4,000 lines of code.
The Markdown instructions must cover platforms and repeatedly enforce checkout boundaries
The new instructions include separate behavior for Windows, Linux, and macOS. They tell the model to run setup scripts for each worktree and to keep operating inside the assigned checkout. Gomes calls this the hardest part because the model must be told aggressively not to work elsewhere or escape the worktree. The commands are called /worktree, /best-of-N, /apply-worktree, and /delete-worktree. They are implemented as commands rather than user-created skills so Cursor can update their prompts on the server without requiring a client update.
A parent agent can compare model outputs and combine selected changes
In the demonstrated best-of-N workflow, the parent agent creates five subagents for Kimi, Grok, Composer, GPT, and Opus, with a separate worktree and context for each. After the agents finish, the parent compares their implementations and explains where they differ. Gomes says a user can then ask it to combine a part from Opus with a part from GPT. This gives the parent more context about each submission than the old judging experience, where the user had to choose one model and keep that result.
The smaller implementation improves maintenance and several workflows
Gomes's main benefit is the reduction in code for an advanced feature used mostly by Cursor power users. Users can now switch into a worktree halfway through a chat by entering a slash command, rather than choosing a mode in the initial interface. The new command also supports projects split across multiple repositories. Cursor creates a worktree for each repository and can open a pull request for each one. The parent agent's richer view of subagent results also makes it possible to ask for a combined implementation.
Prompt-based isolation is less reliable than preventing file access in code
The old implementation made it physically impossible for an agent to touch files outside its worktree. The new version trusts the model to follow instructions, which Gomes describes as somewhat vibes-based. During long sessions, a model may forget its assigned directory. Weaker models may hallucinate or start changing files in the wrong place. The workflow can also feel slower because users see the agent create a worktree in the chat, even though Gomes says the operation is not actually slower. Discoverability is worse because the old worktree dropdown is gone, so users must know to type /worktree.
Evals can test both the intended worktree and the protected primary checkout
Cursor is building evals to improve the prompts. Gomes runs the headless Cursor CLI and uses two scorers. One checks whether the model did work in its assigned worktree. The other checks whether it changed anything in the primary checkout, where it should not work. His early tests show that models differ substantially. Haiku often deviates into the primary checkout, while Composer and Grok perform better in his tests. The evals do not yet reproduce very long sessions, where the failure rate can increase, but Gomes plans to use them to find prompt improvements and add better system reminders.
Cursor plans native worktrees and non-Git parallelization
Cursor is building a more complete, native worktrees implementation for the new agent-focused window associated with Cursor 3.0. Gomes says this interface is a better place for local parallel work because its users are more likely to run several agents. Cursor will continue improving the Markdown commands through evals, reinforcement learning, and other training. The company is also exploring alternatives to Git worktrees because they can be slow to create, use substantial disk space, and only work in Git repositories. Gomes says Cursor is looking for local parallelization primitives that do not depend on Git.
"One that checks to see if the model did any work in its work tree as expected, and then another one, which is the reverse of that, which is did the model do any work in the primary checkout where it shouldn't be doing any work."15:49
Who should watch
You maintain an agent workflow with a large amount of product code and want to judge whether prompts can replace some of it.
Your coding agents work across repositories or need isolated parallel checkouts with results compared afterward.
You are evaluating prompt-based tool isolation and want concrete failure cases, eval design, and training approaches.
