Use case · Parallel Cursor

Run multiple Cursor agents in parallel

ParallelCode pairs Cursor with Git worktrees so you can open several Cursor windows on different branches at the same time — no manual checkout, no shared filesystem chaos.

Why parallel Cursor is hard without a worktree manager

  • A single repo only checks out one branch at a time, so two Cursor windows on the same folder fight over files.
  • Manually creating Git worktrees with the CLI is error-prone (orphaned branches, “cannot remove worktree” errors).
  • When Cursor agents go long, you need somewhere else to work — switching branches mid-flight wipes context and breaks the agent.
  • Background agents in Cursor still run inside one workspace; they can stack up but not truly fan out across branches.

How ParallelCode makes Cursor parallel

  1. 1

    Create a worktree per task

    Click “New worktree” in ParallelCode, pick a base branch and a name. Each worktree is a real folder on disk that Cursor can open as a workspace.

  2. 2

    Launch Cursor in each worktree

    Open every worktree in its own Cursor window. Each window has independent files, terminal, chat history and Cursor agent state.

  3. 3

    Run agents in parallel

    Kick off long-running Cursor agents simultaneously: refactor in one window, write tests in another, fix a bug in a third. Nothing waits on anything.

  4. 4

    Merge or discard with one click

    When an agent finishes, ParallelCode shows the worktree’s Git status, commits and merges. Drop a worktree to throw away a failed experiment.

FAQ

Can I really run multiple Cursor windows on the same repo?

Yes — but only if each window points at a different working directory. That is exactly what Git worktrees provide, and what ParallelCode automates.

How is this different from Cursor background agents?

Cursor background agents queue work inside one workspace, on one branch. Parallel worktrees let multiple Cursor agents work on different branches truly in parallel — useful when changes can’t share files.

Will I run out of disk space?

Git worktrees share the underlying object store, so the disk overhead is roughly the size of your tracked files, not a full repo clone per branch.