Move_agent_to_root AgentMigration clones one chat into two live auto-resumed sessions

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When an agent calls cursor-app-control → move_agent_to_root to switch into a git worktree, Cursor runs [AgentMigration] and copies the conversation into a new composer ID in a new workbench. The source chat is aborted with abortReasonMessage: “migration” but is not torn down.

If move_agent_to_root is invoked twice in the same turn (the first call is cancelled by the migration abort, then the agent retries), AgentMigration runs twice about 8 seconds apart. Both clones restore the same history and auto-resume with no user message (isResume: true, textLength: 0). Two same-title agent sessions then keep editing the same worktree in parallel.

This is not the documented Fork chat action. Docs say a worktree move continues the same chat.

Steps to Reproduce

  1. Open a long Agent chat in a git repo.
  2. Have the agent create a git worktree and call move_agent_to_root to that path (the using-git-worktrees skill does this).
  3. Repeat for a second worktree in the same chat.
  4. On a later move, if the first move_agent_to_root is cancelled (Tool call was cancelled / abort_chat_and_wait_for_finish from beginMigration) and the agent retries the same tool in the same turn, logs show two [AgentMigration] Starting worktree→local migration events with two different composerIds.
  5. Both new composers auto-resume. The source composer in the previous workbench can also keep running.

Expected Behavior

One conversation continues in the new worktree. The source composer is stopped. Concurrent or retried move_agent_to_root calls for the same chat must not create a second live clone that auto-resumes.

Operating System

MacOS

Version Information

3.18.9 (client_version from Composer structured logs, 2026-09-01)

For AI issues: which model did you use?

grok-4.6

For AI issues: add Request ID with privacy disabled

3bcaef47-efb6-481f-92a7-be9b7d7ddc73
5be36c30-90d2-4d4c-aadd-03fac7bcc41c
44b7780a-de6d-48cb-9ca5-f0278f59d7dd

Additional Information

Observed 2026-09-01 ~17:06 local (Europe/Amsterdam) in Cursor structured logs:

  • 17:06:36 abort source composer ab4537e9 (migration). MCP move_agent_to_root cancelled.
  • 17:06:37 [AgentMigration] Starting worktree→local migration for composer 17059208. New workbench created (isNewWorkspace: true).
  • 17:06:45 second abort + second cancelled move_agent_to_root. Second migration starts for composer ee9a9889.
  • 17:06:46 17059208 migration complete, auto-resume.
  • 17:06:53 ee9a9889 migration complete, auto-resume.

Those two transcripts were identical for the first 294 lines, then both agents kept working on the same branch.

Related (same tool, different failure modes):

Expected fix: continue the same composer (do not mint a new ID), stop the source, and de-dupe in-flight AgentMigration for one conversation.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

Hey @Klaas_Hulder, We’ve let the team know; it’s an issue we’re tracking.

Until it’s sorted, two things help:

  • Stop the agent before it moves into a worktree.
  • If extra copies do appear after a move, stop them right away so they don’t keep editing the same worktree in parallel.

I’ll post here when there’s an update.