Cursor 3.2 Adds /multitask Async Subagents, Worktrees Polish, and Multi-Root Workspaces

Cursor released 3.2 on April 24, 2026, three weeks after the Cursor 3 Agents Window launch and nine days after Cursor 3.1 added canvases. The headline of 3.2 is parallelism: a new /multitask command runs async subagents instead of queueing requests, the worktrees experience now runs isolated branch work in the background by default, and multi-root workspaces let a single agent session target multiple folders at once for cross-repo work.

For where 3.2 sits in the broader Cursor surface, see our Cursor canvases coverage and the Cursor vs Claude Code comparison.

Key Takeaways

• Launch date: April 24, 2026, as Cursor 3.2.
• /multitask command: Cursor "will run async subagents to parallelize your requests instead of adding them to the queue," and will "break down larger tasks into smaller chunks for a fleet of async subagents to tackle simultaneously."
• Worktrees upgrade: "Run isolated tasks in the background across different branches. When you're ready to test changes, move any branch into your local foreground with one click."
• Multi-root workspaces: "A single agent session can now target a reusable workspace made of multiple folders," enabling "cross-repo changes spanning frontend, backend, and shared libraries, without retargeting the agent every time it moves between repos."
• Why it matters: Cursor is closing the loop on parallel agent work that started with the Cursor 3 Agents Window. Queueing was the obvious 3.0-era pattern; async subagents are the 3.2-era pattern.

What /multitask Actually Does

Before 3.2, the way you handed Cursor more than one task at a time inside a single agent session was the queue: type the next request and Cursor would append it after the current one finished. That works, but it serializes work that does not need to be serialized -- there is no dependency between "rename foo to bar in src/" and "add a new test for baz," but the agent ran them one after the other anyway.

/multitask is the parallel alternative. From Cursor's 3.2 changelog: "With /multitask, Cursor will run async subagents to parallelize your requests instead of adding them to the queue." A single command can fan one large task out into smaller subtasks too -- "Cursor will break down larger tasks into smaller chunks for a fleet of async subagents to tackle simultaneously." The user-facing experience is closer to "delegate the whole batch and watch the results come back" than "wait for each item."

The honest use case is a list of independent edits across a codebase -- mass renames, parallel tests to add, multiple small refactors to apply across modules -- where each subtask has its own scope. Tasks with hard dependencies still need queueing or explicit step-by-step prompting. Cursor does not promise dependency-aware scheduling here.

Worktrees: Background Isolation, One-Click Foreground Swap

Cursor 3 introduced the /worktree command for creating a separate git worktree so changes happen in isolation. Cursor 3.2 evolves the experience around it. The new framing: "Run isolated tasks in the background across different branches. When you're ready to test changes, move any branch into your local foreground with one click."

The behavior split is the important part. Before 3.2, switching to test a branch meant either swapping your editor view or running the worktree CLI commands by hand. Now the agent can keep running across branches in the background, and you reach into one only when you want to test it. The mental model is closer to "agents run on every branch I care about, I check on them when ready" than "I drive the agent on one branch at a time."

This pairs naturally with /multitask. A multitask request can spawn worktree-isolated subagents on different branches, run them all in parallel, and let you bring whichever branch's result you like back into the foreground first.

Multi-Root Workspaces: One Session Across Many Folders

The third change is the most architecturally significant. A multi-root workspace is a saved Cursor workspace whose root is multiple folders, not one. The 3.2 changelog framing: "a single agent session can now target a reusable workspace made of multiple folders," letting you "make cross-repo changes spanning frontend, backend, and shared libraries, without retargeting the agent every time it moves between repos."

The problem this solves is concrete. A real feature in a microservice team might span:

• The web repo (UI)
• The api repo (backend)
• The shared-types repo (TypeScript types used by both)

Before 3.2, asking Cursor to ship a feature across all three meant either opening one repo at a time and re-explaining context every switch, or stacking the repos as folders and accepting that the agent's mental model of "the project" was unstable as it moved between roots. Multi-root workspaces make the workspace itself the unit. The agent session understands all three roots are part of the same project; cross-repo edits land in one continuous flow.

The honest caveat: this is most useful for teams that already have a multi-repo setup. Teams in a true monorepo will see less benefit -- one root already covers everything. Teams that have consciously chosen polyrepo for organizational or release-cycle reasons get the largest win.

How These Three Pieces Fit Together

The unifying frame for 3.2 is parallelism without context loss:

1. /multitask makes parallel work the default at the task level.
2. Worktrees make parallel work the default at the branch level.
3. Multi-root workspaces make parallel work the default at the repo level.

Stack them and you get a single agent session that can run several subtasks in parallel, isolate each in its own branch, and span more than one repo at the same time. That is a meaningful step beyond what 3.0's Agents Window shipped, and it lines up with the broader agentic IDE thesis Cursor has been pushing since the Agents Window launch.

How Cursor 3.2 Compares to Claude Code and Codex

The three frontier coding tools have converged on subagents as the unit of parallelism, but each shapes the surface differently:

| Tool | Parallel primitive | Cross-repo story | Background execution | |---|---|---|---| | Cursor 3.2 | /multitask async subagents | Multi-root workspaces, native | Worktrees in the background, one-click foreground | | Claude Code | Task tool subagents | CLAUDE.md per repo, you orchestrate | --bg background flag for long tasks | | Codex | Thread automations + computer use | Repo-by-repo via in-app browser | Persistent threads watching Slack/email/PRs |

Cursor's strength after 3.2 is the editor-native shape of all three primitives -- you stay in the same window, you see all the agents in the Agents Window, the multitask fan-out and the worktree swap and the multi-root targeting all live in the same UI surface. Claude Code's strength is depth of subagent composition for a single repo. Codex's strength is "the agent watches the world for you" via thread automations. They are not interchangeable.

For a deeper architectural comparison, see Codex CLI vs Claude Code vs Cursor architecture. For how Cursor's automation surface differs from Claude Code's, see Claude Code Routines vs Cursor Automations.

What to Try First

Three concrete first sessions on Cursor 3.2:

1. Run a /multitask mass refactor. Pick a task with several independent subtasks -- rename a function across modules, add tests for three sibling components, sweep a typo across the codebase -- and hand the whole batch to /multitask. Watch how the wall-clock time compares to the same batch in the queue.
2. Set up a multi-root workspace for a real cross-repo change. If your team has a frontend repo and a backend repo, save a workspace that includes both, then ask Cursor to ship a small end-to-end feature (a new field that flows from API to UI). Note where it stops to ask for retargeting versus where it just keeps going.
3. Send a long-running task to a worktree branch and keep coding. Use /worktree to start a refactor in an isolated branch, keep working on main in the foreground, then swap into the worktree branch when the agent finishes. The worktree experience is now structured to make that the default flow rather than a CLI exercise.

What This Tells You About Where Cursor Is Heading

Three inferences from 3.2's shape:

• Subagents are now the default unit of work in Cursor, not the queue. /multitask is a soft sunsetting of "send one thing at a time." The 3.x curve is going to keep flattening parallelism into the editor.
• The Agents Window is becoming a panel of many concurrent agent sessions. Worktree backgrounding and /multitask both push more agents into more states at the same time. The UI tax of managing all of them is the next problem to solve.
• Multi-root is a thesis bet on polyrepo teams. Cursor is signaling that polyrepo is a first-class shape, not a degraded monorepo. That is consistent with the enterprise customer base they have been pursuing -- microservice teams at large companies.

For Cursor users specifically, the 3.2 update changes the default for "how do I send the agent more than one task." The answer was queue; the answer is now /multitask. If you are using Cursor primarily for sequential single-task work, you can ignore most of 3.2. If you are running batches, isolating long tasks in branches, or working across more than one repo, 3.2 is the largest agent-experience upgrade since the original Agents Window.

The Cursor 3.2 changelog is the canonical reference for what shipped on day one. Pair it with the Cursor 3 launch post for the architectural through-line and our Cursor canvases coverage for the 3.1 piece in the middle.