Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
cursor-app-control → move_agent_to_root hard-fails when Cursor tries to check out a migrated branch that no longer exists on the remote (typical after merge + delete-branch + worktree cleanup).
Verbatim UI error:
Failed to move agent root: Failed to checkout migrated branch "feat/github-actions-templates": Command failed: git fetch origin refs/heads/feat/github-actions-templates:refs/remotes/origin/feat/github-actions-templates --no-tags --recurse-submodules=no --no-write-fetch-head
fatal: couldn't find remote ref refs/heads/feat/github-actions-templates
This is a different failure mode from the existing worktree-checkout conflict report (Move_agent_to_root MCP fails in git worktrees) — that one fails with “branch is already used by worktree”. Here the branch is gone from origin, and migration still insists on fetching it by name.
Evidence
-
Branch lifecycle was normal. PR merged and remote branch deleted:
- jsolly/dotagents#32 merged 2026-07-09T14:08:56Z, head feat/github-actions-templates
- GitHub branch API → 404
- Local worktree …/code/.worktrees/dotagents/github-actions-templates removed after merge
-
Cursor still binds the agent/workspace to the deleted path. workspaceStorage/…/workspace.json still contains folder pointing at that missing worktree. On this machine there are 39 workspaceStorage entries whose folder paths are missing (mostly cleaned-up worktrees).
-
Same class of git failure for another deleted branch the same day (vscode.git log):
2026-07-09 09:43:46.920 [info] > git fetch origin fix/live-provider-premarket-quotes [491ms]
2026-07-09 09:43:46.920 [info] fatal: couldn't find remote ref fix/live-provider-premarket-quotes
Also earlier at 08:49 / 08:50 for the same branch.
-
While the worktree still existed, git logs for that workspace show healthy activity on feat/github-actions-templates (window1_wb4, workspaceId 695ee29de232dd3a965e3ee427e69624). After cleanup, migration still targets that branch name.
-
Tool description for move_agent_to_root says it will fetch/ff-merge the destination; the failure path appears to treat the agent’s remembered branch as mandatory even when the destination path is gone / branch deleted.
Steps to Reproduce
- From an empty-window / home agent, create a linked worktree on a feature branch and call move_agent_to_root to that worktree path.
- Push, merge the PR, delete the remote branch, remove the worktree (git worktree remove + git branch -d).
- Optionally call move_agent_to_root back to the primary checkout (this was attempted in the session; Cursor still retained the old workspace binding).
- Later, reopen the agent chat or otherwise trigger workspace-root migration for that conversation.
- Observe: Failed to move agent root: Failed to checkout migrated branch “” with git fetch … fatal: couldn’t find remote ref.
Expected Behavior
If the migrated branch is missing on the remote (and/or the remembered worktree path no longer exists), move_agent_to_root should:
- fall back to the requested rootPath / primary checkout without requiring that branch, or
- clear/update the stale workspace binding and move successfully to an existing path,
instead of hard-failing the entire move on a deleted remote ref.
Operating System
MacOS
Version Information
Version: 3.10.20
VSCode Version: 1.125.0
Commit: 23b9fb205fe595ea2be29da7214e19762d037fc0
Date: 2026-07-07T07:03:33.071Z
Layout: glass
Build Type: Stable
OS: Darwin arm64 25.5.0 (macOS 26.5.2)
For AI issues: which model did you use?
Grok 4.5 (Cursor agent)
For AI issues: add Request ID with privacy disabled
investigation: 6862686e-d555-49cb-b430-562ddf710d3f
worktree session that created/moved to the branch: 80bcb98c-7f32-42c9-adca-96f838c0ee64
(Data sharing enabled)
Why this shows up for power-user / worktree workflows
This is likely uncommon for users who open one folder and stay there. My agent setup manufactures the exact lifecycle that trips the bug:
- Worktree-first authoring — local rules require change-making work in a git worktree off
main(enforced by a write guard that blocks edits on amaincheckout). - Home / empty-window →
move_agent_to_root— Cursor home-workspace guidance +cursor-app-controlMCP instruct the agent to callmove_agent_to_rootonce the worktree/project path is known, so the conversation binds to that disposable checkout. - Early worktree cleanup — after PR open (fire-and-forget ship), the worktree is removed at PR creation, not after merge.
- Delete head branches on merge — GitHub
delete_branch_on_merge=trueremoves the remote ref once the PR lands.
Cursor still remembers the migrated branch / workspace path after (3)+(4). Reopen or remigrate → git fetch of a deleted ref → hard fail.
On this machine that pattern is heavy (~30 workspace bindings to worktrees; ~39 workspaceStorage entries pointing at missing paths). Same class of failure the same day for another deleted branch (fix/live-provider-premarket-quotes).
So: not a weird git config — high-churn agent + worktree + ship-cleanup + delete-on-merge. Cursor’s move logic doesn’t handle “that branch is gone” yet.
Additional Information
Related: closest cousin (different error) Move_agent_to_root MCP fails in git worktrees — branch already used by worktree / hang variants. Mohit noted broader worktree migration gaps.
No exact match found for “Failed to checkout migrated branch” + “couldn’t find remote ref” after merge/delete.
Workaround: Open the primary repo with File → Open Folder and start a fresh chat there. Avoid reopening agent chats rooted in deleted worktrees. Pruning stale origin/* refs does NOT stop the failure (Cursor fetches the branch by name from remembered state).
Logs attached: cursor-move-agent-root-deleted-branch-20260709.zip (74.6 KB) — vscode.git excerpts + workspace/git evidence; emails redacted. Happy to pull more windows if useful.
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor