Cursor 3.2 Adds /multitask for Parallel Agent Runs and Better Worktrees

Cursor pushed version 3.2 on April 24, three weeks after Cursor 3 launched with the new Agents Window interface. This update is focused on one problem: making it easier to run multiple agent tasks at the same time without manually juggling sessions.

/multitask: Parallel Agents on Demand

The headline addition is /multitask, a new command that tells Cursor to break a larger request into parallel async subagents instead of handling everything sequentially.

Before this, if you submitted a request while another agent was running, it went into a queue. You could see it was waiting, but you couldn’t move it forward without finishing the current task first. With /multitask, Cursor will either spin up async subagents to run your requests simultaneously, or it will break a single large request into smaller chunks and assign those to subagents running in parallel.

The practical difference is substantial for the kind of work developers actually do. Asking an agent to write tests for three separate modules, refactor a utility function while running a linter pass elsewhere, or investigate a bug in one part of the codebase while generating documentation for another — all of these benefit from parallel execution. Sequential queuing meant waiting on whichever task was slowest.

You can also apply /multitask retroactively. If you have messages already queued up waiting for a running task to finish, you can type /multitask to kick those pending requests off as async subagents instead of continuing to wait.

Worktrees in the Agents Window

Cursor 3.2 also revamps worktrees inside the Agents Window. The previous worktree experience was functional but rough around the edges. The new version makes branch-isolated background work a cleaner operation.

Each worktree runs its own isolated agent task on a separate branch. You can have multiple worktrees active at once, each with its own agent working through a change. When you’re ready to test a branch’s output, a single click moves it into your local foreground — no manual git worktree commands or branch-switching.

This pairs well with the async subagent work: you can use /multitask to kick off parallel subagents and then see the results organized across worktrees, each with its own branch state.

Multi-Root Workspaces

The third feature is multi-root workspaces: a single agent session can now target a workspace made up of multiple folders across different repositories.

The use case is cross-repo changes. Most real software spans multiple repos — a frontend, a backend, shared libraries, infrastructure config. Before multi-root workspaces, an agent session was scoped to a single folder, which meant manually retargeting the agent every time work moved between repositories.

With multi-root workspaces, you define a reusable workspace that includes all the relevant folders. The agent session can then make changes across the frontend and backend in the same session, without being retargeted. The workspace configuration persists, so you set it up once.

As Cursor describes it: “A single agent session can now target a reusable workspace made of multiple folders” — with changes spanning “frontend, backend, and shared libraries” as first-class.

Where This Fits in Cursor 3

Cursor 3.0 introduced the Agents Window on April 2 as an interface built from scratch around managing multiple agents. 3.1 (April 13) added tiled layouts and upgraded voice input. 3.2 completes the parallelism story: now that you can run agents across repos and branches in a unified interface, you need a clean way to kick off many of them at once. /multitask is that.

The update is available now through Cursor > Check for Updates or by downloading from cursor.com.

---

Sources: Cursor Changelog (Apr 24, 2026), cursor_ai on X, Lee Robinson on X