One Cursor task in one editor window is manageable. Several Cursor tasks in the same repo are harder: branches blur together, local state gets mixed, and it becomes unclear which task owns which changes.
The same checkout makes the problem worse. Two agents can edit the same files, overwrite local state, or leave unrelated changes in one diff.
Conductor puts each independent Cursor task in its own worktree-backed workspace. The workspace keeps the branch, chat, terminal, run scripts, diff, checks, pull request, and archive state together.
Conductor supports Cursor's Composer 2.5 as a first-class session agent, so Composer 2.5 work can use the same workspace, review, and PR flow as Claude Code and Codex.
Use one workspace per independent Cursor task
Conductor's unit of independent work is a workspace. Each workspace is backed by a git worktree, gets its own branch and working directory, and keeps its terminal, diff, checks, and pull request path separate.
Use a separate workspace when a Cursor task can become its own branch, review, or pull request. This fits independent features, bug fixes, issue work, and experiments.
Use multiple chats in one workspace only when the Cursor sessions need the same branch and current code state, such as one session implementing while another reviews the same diff.
Split sessions by task
If a Cursor task can become its own branch or pull request, give it its own workspace.
Use worktrees for isolation
Each workspace gets its own branch and working tree, so Cursor is not sharing a checkout with another agent.
Keep runs attached to the branch
Use the workspace terminal or Run button so tests and servers run against the branch Cursor changed.
Review from one UI
Review each Cursor diff, track checks, merge branches that pass review, and archive the rest.
For the full step-by-step workflow, see Run multiple Cursor sessions in parallel.
Where Cursor's native surfaces fit
Cursor's IDE and background agents are useful when the agent workflow should stay close to Cursor. Conductor is useful when each task needs the surrounding workspace workflow too: copied local files, setup scripts, run scripts, terminals, diff review, checks, and pull request handoff.
Conductor can also open a workspace in the Cursor IDE. Use that when editing in Cursor is the right surface, while Conductor keeps the branch, setup, review, and PR flow organized.
Set up Cursor before creating several workspaces
Cursor sessions, including Composer 2.5, need a Cursor API key. Add it in Settings -> Providers -> Cursor, or set CURSOR_API_KEY in Conductor's environment settings.
Parallel Cursor sessions work best when a new workspace can run the project without manual repair. Put static gitignored files in Files to copy. Put dependency installation, generated files, symlinks, local database setup, and other repeatable preparation in setup scripts.
If several workspaces need local dev servers at once, use CONDUCTOR_PORT so each workspace gets a separate port range.
Before you start several agents
Prepare the repo once so each workspace starts cleanly.
- Give every agent a task that can finish independently.
- Copy required `.env` files or configure Files to copy before creating workspaces.
- Move generated setup into setup scripts instead of doing it by hand.
- Use `CONDUCTOR_PORT` when several workspaces need local servers.
- Avoid assigning two agents the same broad file-heavy refactor.
- Review, merge, or archive one workspace at a time.
Common patterns
For issue work, create one workspace per issue, give each Cursor session a narrow prompt, and review the resulting branches separately.
For implementation plus review, keep both sessions in one workspace if the reviewer needs to comment on the same in-progress diff.
For mixed-agent work, run Cursor, Claude Code, and Codex in separate workspaces when their tasks can ship separately. Use one workspace when they need the same branch and latest local state.