Feature request: queue a supplementary task while a task is running instead of interrupting it

Feature Request: Queue a supplementary task while the current one is running

Summary

When a task is already running in Claude Code UI, I want to be able to submit a supplementary / follow-up task (extra context I forgot, or a clarification that would otherwise send the work in the wrong direction) and have it run automatically right after the current task finishes — not interrupt the running one.

Problem

I often hit this exact flow: I start a task, and a few seconds later realize I forgot an important detail or need to correct the direction of the work. Right now there is no way to "append" that context for the upcoming run without derailing the current one. If I submit it immediately, it would cut off / interfere with the running task. If I wait, I risk losing the thought entirely.

Proposed behavior

1. Task A is running.
2. I submit Task B (a supplement to Task A) while A is still executing.
3. Task B is placed in a queue and shown as pending (e.g. a "1 task waiting" indicator).
4. When Task A completes, Task B starts automatically.

Key requirement

• The new task must be queued, not inserted immediately. It must wait until the current task finishes before it starts, and must not interrupt or hijack the running task.

Why this matches Claude Code CLI

In the Claude Code CLI, when you type new input while a run is active and press Enter, the new task is applied automatically to the conversation. The UI should offer the same convenience — being able to submit input at any moment — but with a queue so the currently running task is never derailed.

Nice-to-haves

• A visible queue indicator so the user knows a follow-up is pending.
• Ability to cancel or reorder queued tasks.
• Optionally, a toggle for "interrupt now" when the user explicitly wants immediate execution.

Use case

• Task: "Refactor the payment module."
• 30 seconds in, I realize: "Also update the related tests and the API docs."
• With this feature: the refactor finishes first, then the follow-up runs automatically with the extra context.
• Without it: I either interrupt the refactor (risking a half-done state), or I wait and risk forgetting the follow-up.