[Feature]: Parallel queued tasks in the interactive TUI (Cursor-style `/multitask`)

[NkAntony777]

[Feature]: Parallel queued tasks in the interactive TUI (Cursor-style /multitask)

Product or interface

CLI - interactive TUI

Use case and problem

While a long-running task is executing, I frequently queue follow-up prompts with Alt+Enter — e.g. "add unit tests for the edge cases in parser.ts", "update the README install section", "run the linter and fix the findings". Today the queue is strictly sequential: each queued prompt waits for the previous turn and all of its tool calls to finish before it even starts. Three independent ten-minute tasks cost thirty minutes of wall-clock time, and the session sits idle while I wait for work I already described.

Cursor solved exactly this with its multitasking release (Cursor 3.2, 2026-04-24). With /multitask, Cursor runs async subagents that parallelize requests instead of adding them to the queue, and can decompose a larger request into chunks for "a fleet of async subagents to tackle simultaneously". Crucially, when messages are already queued, Cursor lets you multitask them with a click instead of waiting for the current run to finish — the user never has to choose between "wait for the whole queue to drain" and "cancel the running task".

MiniMax Code already has the hard parts in place — subagents, background tasks, and the session/queue runtime. What is missing is a user-facing way to dispatch queued tasks to run concurrently instead of draining the queue strictly in order.

Desired behavior

A one-click "Multitask" affordance on the queue (with /multitask as the keyboard-equivalent slash command) that converts queued prompts into parallel async subagents — without waiting for, or cancelling, the current run:

> "Refactor the parser to use the new token API"          (running, ~10 min)
Alt+Enter   "Add unit tests for edge cases in parser.ts"
Alt+Enter   "Update docs/README.md install section"
Alt+Enter   "Run the linter and fix the findings"

  ┌─ queued (3) ────────────────────────────────┐
  │ 1. Add unit tests for edge cases…            │
  │ 2. Update docs/README.md install section…    │
  │ 3. Run the linter and fix the findings…      │
  └─ [ Multitask queued messages ] ──────────────┘   <- one click

  -> dispatched 3 async subagents (2 running, 1 held by concurrency cap)
  -> the current run keeps going; nothing is cancelled or restarted
  -> main session stays interactive; new prompts still accepted
  -> subagent 1 done: 2 files changed, tests pass
  -> subagent 2 done: 1 file changed
  -> subagent 3 blocked: needs a permission decision -> surfaced in main session

Key semantics (adapted from Cursor's design to MCode):

• Queue parallelization, click-first — queued prompts run concurrently as async subagents instead of one-at-a-time; a click on the queue dispatches them immediately, while steps with an explicit dependency keep their order.
• Slash-command parity — /multitask performs the same dispatch for keyboard-only users.
• Auto-decomposition (later phase) — the agent may split a large task into independent chunks dispatched to a fleet of async subagents.
• Context isolation — each subagent runs in its own context window with the task passed in its dispatch prompt; the parent session receives only the final summary, keeping the main conversation clean.
• Filesystem isolation opt-in — for tasks whose edits may overlap, subagents run in git worktrees and their changes are applied back to the working branch after review, instead of interleaving edits in one checkout.
• Concurrency cap + usage guard — a configurable max-parallel limit (e.g. default 3) and a warning/cap before fan-out consumes the Token Plan (see Usage-limit retry loop after rapid verifier/session fan-out #108, where subagent fan-out ran past the usage limit).

Suggested acceptance criteria:

• A clickable affordance on the queued messages dispatches all queued prompts as async subagents without waiting for the current run to finish and without cancelling it; /multitask provides the same dispatch from the keyboard.
• Independent queued tasks run concurrently; explicitly dependent tasks stay sequential.
• Each subagent's final result (files changed, commands run, pass/fail) is surfaced back in the main session, with a way to open the full sub-session.
• Permission prompts raised by a subagent surface to the user instead of silently failing or hanging.
• A concurrency limit and a fan-out cost guard are configurable; exceeding them warns instead of silently spawning more agents.
• Optional worktree isolation for subagents whose edits may overlap; results apply back as a reviewable diff.

Platform

Multiple platforms

Alternatives and additional context

What I tried / considered:

• Multiple mcode sessions in separate terminals — the current workaround. It works until concurrent processes contend on the shared runtime-state.sqlite and turns intermittently die with database is locked ([Bug] Concurrent mcode processes kill each other's turns: SQLITE_BUSY on shared runtime-state.sqlite #282). Making shared runtime-state writes safe under concurrency looks like a prerequisite for in-process parallelism too.
• Letting the agent spawn subagents on its own — the desktop app already fans out subagents/background tasks, but the CLI TUI has no explicit "run my queued list in parallel" affordance, and no per-task status or result surfacing in the main session.
• Doing nothing — the sequential queue is predictable and cheap to reason about; parallel dispatch adds coordination and merge cost for tightly-coupled work. An explicit opt-in (click or /multitask) keeps today's behavior as the default.

References:

• Cursor 3.2 changelog, "Multitask, Worktrees, and Multi-root Workspaces" — /multitask parallelizes requests instead of queueing them, and queued messages can be multitasked without waiting for the current run: https://cursor.com/changelog/04-24-26
• Cursor changelog, "PR Review, Build Plan in Parallel, and Split PRs" (parallel plan execution, split changes into PRs): https://www.cursor.com/changelog/05-07-26
• Cursor docs, "Subagents" (async/background subagents, context isolation, nested subagents)

Related issues in this repo: #282 (concurrent-process SQLite contention), #108 (subagent fan-out past the usage limit).

Per the collaborators-only PR policy I am opening this as an issue rather than a PR. Happy to test a beta build and report back.