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

Status (September 1, 2026): the 3.2 changelog entry stands, but Cursor's current docs no longer describe /multitask, and worktrees and multi-root workspaces do not combine. Details in "What Cursor's Documentation Says Now" below.

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.
• They are not a stack. Cursor documents worktrees as disabled inside a multi-root workspace, and Cloud Agents as not supporting multi-root at all, so 3.2's second and third features are a choice rather than a combination. (updated September 1, 2026)
• Where the parallelism surface went. /multitask appears on no page of Cursor's current documentation; Subagents, with foreground and background modes, is what Cursor documents today. The 3.2 changelog entry is unchanged and unretracted. (updated September 1, 2026)

What Cursor's Documentation Says Now

Documentation status: /multitask is no longer described anywhere in Cursor's documentation. We fetched all 142 pages indexed in cursor.com/docs/llms.txt on September 1, 2026 and searched them. The only occurrence of the string is the ordinary verb in the Design Mode page ("This makes it easy to multitask and manage several subagents at once"); there is no /multitask slash command in the Agents Window docs, the Subagents docs, or the CLI slash-command reference. This is not evidence that the command was removed -- the 3.2 changelog entry is still live and unretracted -- but the documented parallelism primitive in Cursor today is Subagents, which has explicit foreground and background execution modes, three built-in subagents (Explore, Bash, Browser), and cloud subagents that hand work to a separate VM and branch. If you are picking a parallelism surface in September 2026, that is the one Cursor documents.

Two eligibility facts this page never carried. First, the UI-native worktrees flow is Agents Window only: "The UI-native worktrees feature described on this page is only available in the Agents Window. In the IDE, use the Worktree Skills commands below." (Cursor, Worktrees) Second, the Agents Window itself was gated at launch: it went generally available with Cursor 3 on April 2, 2026, and "for the two weeks following launch, Enterprise Admins can control rollout within their organizations by giving access to their entire team or to specific users via Team settings. After the rollout period, all users will have access by default." (Cursor, Agents Window) That gate has long since lapsed, but it is the answer to "could an admin have turned this off", and it is worth knowing that the rollout control existed.

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, and re-checking its documentation on September 1, 2026 found no scheduling guarantee added since.

What fanning out costs. Cursor's Subagents documentation is blunt about the trade the 3.2 changelog does not mention: "Subagents consume tokens independently. Each subagent has its own context window and token usage. Running five subagents in parallel uses roughly five times the tokens of a single agent." It also notes that "for quick, simple tasks, the main agent is often faster." Parallelism buys wall-clock time and spends included usage, which matters on a plan with a pool rather than a per-seat allowance -- see our coverage of Cursor's doubled usage limits for what that pool actually is. (Cursor, Subagents)

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."

Where this works, checked September 1, 2026. The UI-native version of this flow is Agents Window only. Cursor's worktrees documentation opens by saying so: "The UI-native worktrees feature described on this page is only available in the Agents Window. In the IDE, use the Worktree Skills commands below." Those commands are worth knowing because the 3.2 changelog does not list them:

Setup inside a new worktree is configurable through .cursor/worktrees.json, which Cursor reads when it creates a worktree in the Agents Window, the IDE, or the CLI. It takes setup-worktree, plus setup-worktree-unix and setup-worktree-windows overrides, each holding either an array of shell commands or a path to a script -- the practical use being npm ci and copying a .env in so the isolated checkout can actually run. Cursor explicitly recommends against symlinking dependencies into a worktree. (Cursor, Worktrees)

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 parallel subagent work: a fan-out can put each subtask on its own branch, run them together, and let you bring whichever branch's result you like back into the foreground first. What it does not pair with is a multi-root workspace -- see the correction below.

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.

The price of the second root, checked September 1, 2026. Cursor's documentation states it plainly: "Cursor supports multi-root workspaces. Each workspace folder's context is available to Agent. Some features that rely on a single git root, like worktrees, are disabled for multi-root workspaces. Cloud Agents do not support multi-root workspaces." So adding a second root turns off worktrees in that workspace and takes Cloud Agents off the table entirely. If you were planning to run a long cross-repo refactor on a cloud VM, or to isolate it on its own branch, a multi-root workspace is the wrong container for it. (Cursor, Codebase search and context)

How These Three Pieces Fit Together, and Where They Do Not

The unifying frame for 3.2 is parallelism without context loss, at three different levels:

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.

The first two compose. The second and third do not. This page originally said you could stack all three into one session that runs subtasks in parallel, isolates each in its own branch, and spans more than one repo at the same time. That was an inference across three changelog bullets, and Cursor's documentation rules it out: "Some features that rely on a single git root, like worktrees, are disabled for multi-root workspaces. Cloud Agents do not support multi-root workspaces." (Cursor, Codebase search and context, checked September 1, 2026)

So the real choice in a session is:

That is still 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. It is just a narrower step than this page first described.

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:

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, and the fan-out, the worktree swap, and the multi-root targeting all live in the same UI surface, even though the last two cannot be switched on together. 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. Fan a batch out instead of queueing it. 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 out at once rather than one at a time. Watch how the wall-clock time compares to the same batch in the queue, and watch your included usage too: Cursor documents five parallel subagents as costing roughly five times the tokens of one.
2. Set up a multi-root workspace for a real cross-repo change, and expect worktrees to go away. 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 -- and note that in this workspace /worktree and Cloud Agents are not available, per Cursor's documentation.
3. Send a long-running task to a worktree branch and keep coding. In a single-root workspace, use /worktree to start a refactor in an isolated branch, keep working on main in the foreground, then use /apply-worktree when the agent finishes. In the Agents Window this is the UI-native flow; in the IDE it is the Worktree Skills commands. Add a .cursor/worktrees.json first if the checkout needs npm ci or a copied .env to be runnable.

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 was a soft sunsetting of "send one thing at a time," and the four months since bear it out: Subagents is now a documented primitive of its own, with foreground and background modes, three built-in subagents, and a cloud handoff.
• The Agents Window is becoming a panel of many concurrent agent sessions. Worktree backgrounding and subagent fan-out 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, and it is a costed one. Cursor is signaling that polyrepo is a first-class shape, not a degraded monorepo -- while accepting that a multi-root workspace gives up worktrees and Cloud Agents. That is consistent with the enterprise customer base they have been pursuing, and it is a real constraint rather than a rough edge.

For Cursor users specifically, the 3.2 update changed the default for "how do I send the agent more than one task." The answer was queue; the answer became fanning out to subagents. 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 was the largest agent-experience upgrade since the original Agents Window -- with the caveat, added September 1, 2026, that the last two of those are alternatives rather than a combination.

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.

Corrections and Updates

September 1, 2026: re-checked against Cursor's current documentation; one claim was wrong when it published: worktrees and multi-root workspaces do not stack, and the affected section is corrected.

Sources

• Cursor 3.2 changelog, "Multitask, Worktrees, and Multi-root Workspaces", April 24, 2026. Every quotation in the Key Takeaways and in the three feature sections comes from this entry. Re-fetched September 1, 2026: unchanged and unretracted, all three quotations still verbatim.
• Cursor documentation, "Codebase search and context". Checked September 1, 2026. Source for the multi-root constraints: worktrees and other single-git-root features disabled in a multi-root workspace, and Cloud Agents unsupported there.
• Cursor documentation, "Worktrees". Checked September 1, 2026. Source for the Agents Window restriction on the UI-native flow, the /worktree, /apply-worktree, /delete-worktree, and /best-of-n commands, and the .cursor/worktrees.json setup keys.
• Cursor documentation, "Subagents". Checked September 1, 2026. Source for the foreground and background execution modes, the built-in Explore, Bash, and Browser subagents, cloud subagents, and the token-cost note that five parallel subagents cost roughly five times a single agent.
• Cursor documentation, "Agents Window". Checked September 1, 2026. Source for the April 2, 2026 general-availability date and the two-week Enterprise Admin rollout control after launch.
• https://cursor.com/docs/llms.txt, fetched September 1, 2026. Used as the documentation index for the /multitask search: all 142 pages it lists were retrieved and searched, and the only occurrence of the string is the ordinary verb on the Design Mode page.
• Claude Code CLI reference. Checked September 1, 2026, to re-verify the comparison table's Claude Code row: --bg / --background starts a session as a background agent and returns immediately.