Moving a running local agent into a git worktree forks the conversation instead of transferring it

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Moving a running local agent into a git worktree forks the conversation instead of transferring it.

I started one local agent in the repo. Cursor created a worktree and cloned the chat into it. The original chat got archived and looks aborted, but the run is still marked unfinished. Then a second parent chat in the worktree kept going on the same task. Sometimes a third empty clone with the same title pops up too.

Both parents keep generating. They spawn the same subagents and run the same shell commands. Those commands execute in the same worktree folder, so I get two of the same process on one checkout.

This is not Best-of-N. Same model, same prompt, two chats.

On the forked worktree conversation (request ID starting with 6d0d6c14), the spawned subagents are stuck in a cold-start loop. They stay on “Starting up” forever. Force quitting Cursor does not stop them. They start again on relaunch. There is no way to actually stop them, and they keep consuming my usage limit.

Steps to Reproduce

  1. Start a local agent in a git repository.
  2. While that agent is still running, move it into a git worktree.
  3. Observe Cursor clone/fork the conversation into the worktree instead of transferring it.
  4. The original chat gets archived/aborted but is still marked unfinished.
  5. The worktree parent continues the same task.
  6. Both parents spawn the same subagents and run the same shell commands in the same worktree folder.
  7. On the worktree conversation, the subagents stay stuck on “Starting up”.
  8. Force quit Cursor and reopen. The same subagents start up again. Stop All / force quit does not actually stop them.

Expected Behavior

One agent, one worktree. The original run should be stopped or moved, not forked.

Subagents should be stoppable. Force quitting Cursor should actually stop them. They should not restart in a cold-start loop and burn usage.

Screenshots / Screen Recordings

Screenshot 2026-08-26 at 7.03.10_PM.png
Screenshot 2026-08-26 at 7.03.10_PM.png824Ă—824 33.7 KB

Operating System

MacOS

Version Information

Cursor IDE 3.17.19 on macOS

For AI issues: which model did you use?

Extra High (same model on both forked parent chats; not Best-of-N)

For AI issues: add Request ID with privacy disabled

ed784268-01f1-477b-a711-eaa0082f253e
6d0d6c14-6287-490c-b93f-b73acf5d7c44

The 6d0d6c14 conversation is the worktree clone whose subagents are stuck in the cold-start loop.

Additional Information

Worktree conversation request ID: 6d0d6c14-6287-490c-b93f-b73acf5d7c44
Original / affected conversation request ID: ed784268-01f1-477b-a711-eaa0082f253e

The conversation starting with 6d0d6c14 is the worktree clone (shown as docs/pydantic-alias-generators Worktree). Its subagents stay stuck on Starting up:

  • How alias generators work
  • Why GitHub issue 4270
  • Why docs lag after 2946

The UI shows “3 Working” and a Stop All button, but they do not actually stop. Force quit Cursor and they start again. This is eating through my usage limit with no way to halt them.

cc @deanrie

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report with the request ID, it really helped.

There are two separate things here:

  1. Forking a conversation when moving it to a worktree. Right now, moving a chat to a worktree creates a new conversation there and archives the original, instead of moving it in place. But the original conversation continuing to run in parallel with the new one is definitely not intended. We confirmed what you described and passed it to the team. As a temporary workaround, stop the agent before moving it to a worktree. That should prevent duplicated conversations and duplicate processes in the same checkout.

  2. Subagents get stuck on Starting up and won’t stop. This is a known issue we’re tracking, and a fix is already being prepared for one of the next builds. Your version 3.17.19 doesn’t include it yet, so I’d recommend updating once the update is available.

About the limit usage: based on our data, those stuck 3 Working tiles are an outdated status in the UI. The processes behind them were already stopped when you hit Stop, and they aren’t consuming usage. So the tray numbers are misleading, but there’s no real limit burn happening.

I’ll post here if there’s an update on the first item.

7

Hey Dean, thanks.

I asked Cursor itself about the stuck “3 Working” tiles. This is the exact explanation it gave me:

The three you see are already done. Cursor just never flipped the badges.

I launched them in the background (how alias generators work, plus two history lookups). Their transcripts all end with a successful finish. Background agents stay “running” in the UI until this chat ends a turn and receives the done ping. I kept working in one long turn, then the yarn-install failure and the stalled site build sat in the way, so the UI never caught up.

There is a later re-review agent that was actually stuck on its first tool call. I sent it a stop.

Once this message lands, those three should drop off. If they don’t, that’s a Cursor UI glitch, not live work.

That message landing is what cleared it. The UI glitch is gone now.

8

Great that the 3 Working tiles reset. That matches what we see on our side too. Those tiles were just an outdated status in the UI, the processes behind them were already stopped, and they didn’t affect usage. So you weren’t burning your limit there.

On the first point about the chat forking when moving to a worktree, that isn’t intended behavior, and we’re tracking it. For now, the workaround is the same. Stop the agent before moving it to a worktree, and you won’t get duplicate chats or parallel processes in the same checkout.

I’ll post here if there’s an update on this.