Cannot migrate: failed to detach worktree HEAD — spawn /usr/bin/git ENOENT on deleted worktree cwd

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When finishing work in a dedicated git worktree and switching/migrating the agent back to the primary checkout, Cursor fails with:

Cannot migrate: failed to detach worktree HEAD
(Error executing git: spawn /usr/bin/git ENOENT, cwd: /Users/roberto.caracappa/Desktop/Shiva/.worktrees/occ-2-gate, command: “git checkout --detach”)

Important: /usr/bin/git EXISTS and works from Terminal (Apple Git 2.50.1). The cwd in the error is a linked worktree directory that has already been removed. Node child_process.spawn reports ENOENT for a missing cwd even when the git binary is present — so this looks like a stale/deleted worktree path during agent migration, not a missing git install.

This often happens after a worktree-based agent session (e.g. created under .worktrees/ via agent/superpowers workflows). The failure is in Cursor’s migrate/detach flow, not in the third-party skill itself.

Steps to Reproduce

  1. Open a git repo in Cursor IDE (primary checkout).
  2. Start an agent session rooted in a linked worktree (e.g. .worktrees/).
  3. Finish the work and remove/clean up that worktree so the directory no longer exists (git worktree list no longer shows it).
  4. From that same chat/session, try to migrate/switch the agent back to the primary checkout (the UI that runs git checkout --detach).

Observed: migration fails with spawn /usr/bin/git ENOENT and cwd pointing at the deleted worktree path.

Expected Behavior

If the worktree path no longer exists, Cursor should detect that and fall back to the primary checkout (or show a clear “worktree no longer exists” error) without running git checkout --detach in a deleted cwd. Migration should not fail with a misleading git ENOENT when git itself is installed and working.

Operating System

MacOS

Version Information

Version: 3.26.13
VSCode Version: 1.128.0
Commit: 3bfec373749d3d4a53a151283022d49743ab50b0
Date: 2026-10-20T01:50:17.051Z

For AI issues: which model did you use?

Regardless the model.

Additional Information

  • macOS darwin 25; /usr/bin/git present and executable.
  • Repo uses linked worktrees under .worktrees/.
  • At failure time, cwd …/.worktrees/occ-2-gate did not exist; other worktrees under .worktrees/ still did.
  • Workaround: File → Open Folder on the primary repo root and start a fresh chat (do not migrate from a deleted-worktree session).
  • Related forum reports: agent migration / move_agent_to_root gaps with git worktrees; ENOENT when cwd is a deleted worktree path.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

8

Hey @Deark,

You’re right that this isn’t a missing Git install. When an agent moves from a worktree back to your main checkout, Cursor first runs git checkout --detach inside the old worktree folder to free its branch, and it doesn’t check that the folder still exists. Because .worktrees/occ-2-gate had already been removed, that command fails and Node reports it as spawn /usr/bin/git ENOENT.

Cursor does have a recovery path that skips this step when a worktree has been deleted, but today it only applies to worktrees Cursor created itself under ~/.cursor/worktrees, not ones created elsewhere, like a repo-local .worktrees/ folder. That’s the gap you hit, and it shouldn’t fail this way.

In the meantime, you should be able to let the move go through by putting the worktree back on its branch first:

  1. In a terminal, cd into your main repo folder.
  2. Run git worktree add .worktrees/occ-2-gate occ-2-gate (swap in the branch name if it differs).
  3. Back in Cursor, retry moving the agent to your main checkout.
  4. Once the move finishes, remove the worktree again with git worktree remove .worktrees/occ-2-gate.

This needs the branch to still exist. If it was deleted, your current approach (open the main repo folder and start a fresh chat) is the way to go. You can also check out the branch in the main checkout yourself with git checkout occ-2-gate before opening it there.

If you hit it again, a Request ID from the affected chat would help us match it in our logs.

13

Hi Colin,

Thanks for your reply. I can manage it by just avoid executing --detach before moving to another worktree, but this is something i need to declare or make explicit in .md file for each project I’m working on.