Running Cursor parallel agents safely

Published 2026-05-20 by Owner

Cursor 3.5 added multi-repo automations: agents that work across several codebases at the same time. The capability is real leverage for cross-cutting changes and a real way to overspend and over-trust if you run it without limits. This guide sets those limits. Cursor configures and monitors automations from the Agents Window, so the tool-specific actions below are steps you take there; the code blocks are the repository-side workflow you use to review and gate what the agents produce.

Prerequisites

Cursor 3.5 or newer, with Composer 2.5 available in your model list
The Agents Window open, where automations are configured, monitored, and stopped
Access to your Cursor usage view, so you can read spend per run rather than only per month

The mental model

Every running agent produces its own diff. Five parallel agents are five review surfaces, not one. The failure mode is treating the batch as a single result and approving it together, because that is the moment review stops happening. Bound your concurrency to the number of diffs you can actually read in one sitting, not to the number the interface will let you start. A practical ceiling is three.

Cap the spend before you scale it

The Standard tier looks cheap per token, which is exactly why a per-run budget matters. Read the spend on the current batch in the Agents Window before you launch another wave; if one run is consuming far more than its siblings, stop it and look at what it is doing. Set the smallest batch that still does the job, and raise it only once you have seen what a run actually costs.

Review the batch as a set, not a stream

Each automation lands its work on its own branch or worktree. Pull every diff first and read them as a group, looking for the same mistake repeated across repos — a parallel run amplifies one bad assumption into N copies of it. List what changed across your worktrees before approving anything:

git worktree list
for repo in repo-a repo-b repo-c; do
  echo "== $repo =="
  git -C "$repo" diff --stat main
done

The combined view catches the systematic error that per-repo, one-at-a-time approval hides.

Serial for commit

Use parallel for leverage and serial for commit. Land the result one repository at a time, and run that repository’s own tests before the next merge:

git -C repo-a switch main
git -C repo-a merge --no-ff agent/cross-cutting-change
(cd repo-a && bun run test)

Move to the next repository only once this one is merged and green. A loose batch of unrelated tasks fired off in parallel is the case to avoid: if you cannot describe the single review you will do at the end, you are running parallel-for-coverage, and that is where unreviewed changes ship.

What not to auto-approve

In the Agents Window approval settings, keep auto-approval off for anything that touches credentials, deletes files, or runs shell commands, and leave it on only for read and format actions. Auto-approval across N agents multiplies the blast radius of one bad command by N. Pair this with the runtime stance in AI coding security modes.

Kill a runaway

If an automation has gone down the wrong path, stop it from the Agents Window rather than waiting for it to finish. Then confirm it did not leave a half-staged change behind before you restart with a tighter scope:

git -C repo-a status
git -C repo-a restore --staged .

For why the per-developer footprint matters at all, see parallel agents and the per-developer meter; for the release itself, Cursor ships Composer 2.5 and multi-repo agents.