Cursor worktrees: keep parallel changes separate

For a Cursor worktree workflow, prepare a separate Git working folder and branch for each independent change, then open the intended folder in Cursor. Give every task a clear owner and check its diff before combining changes. Cursor’s Agent overview↗ (opens in a new tab) documents that Agent can read and edit files and run commands. fenbs keeps the branch, checks, and next step together so parallel work does not become a collection of unexplained folders.

The setup below uses ordinary Git preparation. Cursor’s cited Agent guide does not establish a particular worktree creation menu or automatic branch-management workflow, so these steps do not assume one. You control the folders and branches before asking an assistant to change files.

When does a separate worktree help?

A Git worktree gives a branch its own working directory. That lets you keep one change checked out while another sits in a different folder. It is useful when two tasks can proceed independently, such as a documentation fix and a change to an unrelated validation function.

It does not make overlapping edits independent. If two tasks both change the same shared interface, the integration still needs an agreed order and a review. Folder separation helps you see ownership; it cannot decide which version of a design is right.

• Good candidates have a narrow goal, distinct files, and a clear check.
• Poor candidates depend on the other task’s unfinished behavior.
• Shared configuration changes need an owner even when the main source files are separate.

For the separate Codex workflow, see Codex CLI worktrees. Keep the tool-specific setup separate from the general question of whether your two tasks can safely proceed at the same time.

How do you prepare the folders before opening Cursor?

Begin in the repository where you normally work. Check its state and select the starting commit you intend to use. The example creates two new branches and sibling folders from the current commit; replace the names with names that describe your own tasks.

git status --short
git worktree add -b task/search-validation ../app-search-validation
git worktree add -b task/help-text ../app-help-text
git worktree list

1. Read the status output before creating anything. Save or otherwise account for unfinished work using your normal repository process.
2. Choose unused branch and folder names. Check that the starting commit is the base you want for both tasks.
3. Create one worktree for each independent change.
4. Open each folder deliberately in Cursor and confirm which task belongs there before starting Agent.

Follow the repository’s setup instructions inside each folder. Do not assume ignored files, local settings, or installed dependencies are ready merely because the source files are present. Keep credentials out of shared instructions and handoff notes.

What should each assistant check before editing?

Ask the assistant to confirm its directory, branch, and current changes before it begins. Give it one task and a boundary: the files it may change, what belongs to someone else, and the checks that will show the task is complete. These are your working instructions, not an automatic ownership system.

Work only on the search-validation task in this folder.
First confirm the branch and current Git status.
Read the repository instructions before changing files.
Keep the help-text task and shared configuration unchanged.
Report the files changed, checks run, and anything still uncertain.
Stop before combining branches or removing worktrees.

Cursor supports repository instructions through Rules and AGENTS.md. Its Rules guide↗ (opens in a new tab) documents /create-rule and Customize → Rules → Add Rule, with Project Rules stored as .mdc files in .cursor/rules. Those instructions provide context to Agent; they are not permanent model memory.

For a language-specific example, Cursor rules for backend development covers backend instructions. Keep universal repository guidance in the repository and the temporary branch assignment in the task.

Which resources can still collide across folders?

Source isolation is only one part of running work in parallel. Two development processes may still try to use the same port, database, cache location, external account, or output directory. Decide who owns those resources before starting both tasks.

• Assign distinct ports when both tasks need a local server.
• Check where tests write temporary files and generated output.
• Avoid simultaneous writes to a shared development database unless the setup explicitly supports them.
• Name any shared service in the handoff and say whether it is still running.

Do not treat a different folder as a permission boundary. Each assistant should receive only the access required for its task, and you should review any command that would affect shared work. If a setup instruction is unclear, resolve that dependency before increasing the amount of parallel work.

How do you check changes before combining them?

Review each task on its own first. Inspect the changed files, compare the diff with the assigned goal, and run the repository’s relevant checks. Record what passed and what was not run. A clean result in one working folder says nothing about an untested change in the other.

1. Confirm that each task changed only the files it was supposed to change.
2. Check the intended behavior and important existing behavior around it.
3. Choose the integration order, especially where tasks share an interface.
4. Combine the changes using your normal branch review process.
5. Run the relevant checks again on the combined result.

If a conflict exposes incompatible assumptions, stop and resolve the intended behavior before editing conflict markers. The useful outcome is a coherent change with evidence, not simply a file that Git accepts.

What belongs in the handoff before cleanup?

Save the folder, branch, task, current commit when relevant, changed files, checks, and next action. Include any unfinished work and running process. Keep cleanup as a separate deliberate step after the work is safely retained and nobody still needs the folder.

For example, a useful handoff says that validation is implemented but still needs the empty-input check, while the help-text change is ready for review. That tells the next assistant what to do. “Both branches are nearly finished” leaves it guessing which work is safe to continue.

A short explanation of why the branch exists is more useful than its name alone. Our Cursor rules for Bash guide covers command-related instructions, while Cursor chat history addresses finding earlier conversations. Neither replaces a current handoff. More AI at work guides cover keeping that work record useful.

How to keep parallel work clear with fenbs?

Keep each branch’s task, checks, and next step together. You can return to the same place on any device or in another connected AI without guessing which working folder needs attention.

1. Create a free account.
2. Make one task for each change. Write its branch and folder, who is working on it, and what must be checked.
3. Connect Cursor to fenbs so it can read the same tasks and rules as your other connected AIs.
4. After each session, save what changed, which checks passed, and what still needs doing. Say if anything is still running.
5. Start the next session from that saved place. You can carry on from exactly where you left off, on another device or in another AI.

Cursor’s MCP documentation↗ (opens in a new tab) covers its external-tool connection support. fenbs keeps the task and handoff; it does not create, merge, or clean up Git worktrees for you. One small change may be easier to finish in a single working folder.