Git Worktrees in Cursor, Zed, and IntelliJ

git worktrees

Every editor can open a worktree, because a worktree is just a folder. What differs is whether the editor helps you create, list, and switch between them. As of July 2026: Cursor creates worktrees for agents, Zed has a worktree picker, IntelliJ has a Worktrees tab in the Git tool window, and VS Code has no native worktree UI at all.

The universal fallback works in all of them:

git worktree add ../myrepo-auth -b feature/auth

Then open ../myrepo-auth as a folder. Git stores a .git file in a linked worktree pointing back at the main repository, and every editor with git support follows it. You get the right branch, the right diffs, the right blame.

Editors move fast on this. Check the linked docs before trusting any specific menu item below.

Cursor

Cursor’s worktree support is built around agents rather than around you. Per the Cursor worktrees docs, an agent started from the Agents Window can be given its own checkout, so its files, dependencies, and changes stay separate from your main working copy and from other agents.

Three things to know before relying on it:

  • The UI-native worktree feature lives in the Agents Window. In the editor itself you drive it with commands like /worktree and /apply-worktree to bring changes back.
  • Setup steps for a fresh worktree (install, copy env, generate) go in .cursor/worktrees.json, which is the answer to “my agent’s worktree has no node_modules”.
  • Worktrees are stored under a machine-wide root directory, not scattered next to your repo, and Cursor cleans up older ones automatically past a configurable limit.

Because Cursor is a VS Code fork, everything below about VS Code applies too: open a worktree folder in a new window and it behaves like any other project.

Zed

Zed has first-party worktree UI. Per the Zed git docs, you open the worktree picker from the title bar next to the project picker, or by running the git: worktree command.

Three behaviours that surprise people:

  • New worktrees created from the picker start in detached HEAD. Use the branch picker afterwards to create or check out a branch. If you expected to land on a named branch, that’s why you didn’t.
  • The directory for new worktrees is set by git.worktree_directory, defaulting to ../worktrees relative to the repository. Worth setting deliberately, because the default puts them next to your repo rather than inside it.
  • For a multi-root project, Zed creates a linked worktree for each repository when you make one from the picker.

One caveat from the community thread: the rough edges are around branch-in-use errors and finding which worktree holds which branch, especially when agents create worktrees with generated names. git worktree list in the terminal answers that faster than the UI does.

IntelliJ IDEA and other JetBrains IDEs

JetBrains added a native Worktrees tab. Per Use Git worktrees, if a project already has more than one worktree, the Worktrees tab appears in the Git tool window. There’s a New Worktree button, a Delete action, and double-clicking a worktree opens it in a new or existing window.

The documented limits are specific, so read them before building a workflow on it:

  • Worktrees are supported for projects containing a single repository.
  • You cannot check out the same branch in two worktrees (that’s git’s own rule, surfaced in the UI).
  • You cannot delete the main worktree, or the worktree currently open.
  • Do not nest a worktree inside your project directory. JetBrains calls this out explicitly: the IDE starts treating the project as multi-root and worktree integration breaks.

That last one applies everywhere, IntelliJ or not. Nested worktrees confuse editors, file watchers, test runners, and glob patterns alike.

VS Code

No native worktree UI. File > Open Folder on the worktree path, or:

code ../myrepo-auth

The built-in git extension picks up the linked worktree correctly. For creating and switching, either use the terminal or install one of the worktree manager extensions. A multi-root workspace with each worktree as a folder also works, and gives you one window with all of them, at the cost of a shared search scope.

What no editor solves

Editor integration handles the checkout. It does not handle the rest of the loop: installing dependencies in each new worktree, copying gitignored files like .env, keeping track of which window is which branch, or cleaning up when the work merges. That bookkeeping scales badly, and it scales worst when agents are creating the worktrees, because then you didn’t choose the names and you weren’t watching when they appeared.

Cursor’s .cursor/worktrees.json and Zed’s setup hooks are both answers to the same gap. crystl takes the same problem from the terminal side: an isolated session creates the worktree and branch, keeps them in a managed directory instead of scattered around your filesystem, shows which session belongs to which project, and prompts you to merge, keep, or discard on close.

Next