Agents Window "Start multitasking" fails — instructs Task tool with resume: "self" which is rejected

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Clicking Start multitasking on a queued Agents Window message does not start parallel processing.

The UI injects a multitask/fork path that tells the parent agent to call the Task tool with resume: "self". That value is invalid — the Task tool only accepts a real prior agent requestId (or omitting resume). The call fails with an error like:

resume: “self” is not supported. Use a valid requestId or do not specify the resume parameter.

From the user’s perspective the button does nothing / multitasking never starts. Prefixing a new message with /multitask works as a workaround (fresh Task launch without resume:“self”).

Steps to Reproduce

  1. Open the Agents Window in an agent chat.
  2. Start a long-running request so the agent is still processing.
  3. Send a second message while the first is running (it queues).
  4. Click Start multitasking on the queued item / multitask affordance.
  5. Observe that parallel processing does not start; parent agent may attempt Task with resume:“self” and hit the unsupported-parameter error.

Expected Behavior

Queued messages should convert into async subagents and start processing in parallel in the same chat (matching the 3.2 Agents Window /multitask behavior), without requiring a new chat tab.

If conversion fails, the UI should show a clear error — not a silent no-op.

Suggested fix: stop instructing models to pass resume:“self”. Spawn a fresh Task subagent with no resume, or pass a real request/agent id the Task schema accepts.

Operating System

MacOS

Version Information

IDE:
Version: 3.11.19
Commit: bf249e6efb5b097f23d7e21d7283429f0760b740
OS: macOS 26.5.2 (arm64)

For AI issues: which model did you use?

Observed across Agents Window agent sessions (parent model varies; failure is in the Start multitasking → Task resume:“self” path, not a specific model).

Additional Information

Workaround that works: send the parallel request as /multitask <prompt> instead of using the Start multitasking button.

Evidence: when Start multitasking was used, the first Task call failed on resume:“self”; retrying the same work with a fresh Task call (no resume) succeeded. So subagents themselves work — the button’s fork parameter is wrong.

Related UX goal: user wants a second message to start processing while the previous is still running in the same chat; /multitask achieves this, the button does not.

Does this stop you from using Cursor

No - Cursor works, but with this issue

7

The “Start multitasking” button is instructing the agent to launch a Task subagent with resume: "self", and that value is being rejected, so the button ends up doing nothing. I dug into this and it’s on our side, not your setup.

Your workaround is spot on: sending the request as /multitask <prompt> launches a fresh Task without resume: "self", so parallel processing starts normally.

I’ve reported this to our engineering team along with your findings. I’ll follow up here as it progresses.