Allow prompting the main agent while sub-agents are actively working (background sub-agent execution)

Feature Description

Allow prompting the main agent while only its sub-agent(s) are actively working (i.e. the main agent itself is idle, waiting on sub-agent results) — without stopping the session — effectively "backgrounding" the in-progress sub-agent work the way a shell backgrounds a running job (& / Ctrl+Z + bg).

Today, once the main agent has kicked off one or more sub-agents on task x, the session is occupied until that sub-agent work finishes. If I think of an unrelated task y while a sub-agent is running, I have to either wait or stop everything.

The ask is not to prompt an agent that is already running, and not for the user to manually spawn sub-agents. Instead:

• While a sub-agent is actively working (and the main agent is otherwise idle/waiting on it), I should be able to type a new prompt to the main agent at any time.
• The main agent — not the user — decides whether the new prompt warrants spawning an additional sub-agent (e.g. because it's unrelated to the current work) or should be queued/handled some other way.
• The original sub-agent's task keeps running in the background, untouched, while the main agent picks up the new instruction and (at its own discretion) dispatches a new sub-agent for it in parallel.

In short: sub-agent work in flight should behave like a backgrounded shell job — I can keep issuing new prompts to the main agent while its sub-agents work, and it's the main agent's job to figure out how to fit new, unrelated work alongside what's already running, instead of the CLI blocking until the sub-agent(s) complete.

Use Case

While a sub-agent is actively working on task x, I often think of a second, unrelated task y I want handled right away — a quick fix, an investigation, or a separate feature. Right now the CLI won't accept a new prompt to the main agent until the current sub-agent work wraps up (or I abort it), which kills momentum and throws away in-progress work if I do need to interrupt.

What I want is closer to backgrounding a shell process: the sub-agent's task keeps running unattended, and I can immediately hand the (idle) main agent something new. The main agent should use its own judgment — if y is unrelated to x, it can spin up a new sub-agent for y while the original sub-agent continues on x; if y is related or dependent, it can handle it differently (e.g. queue it, or fold it into the existing sub-agent's context). The point is the session should never block me from prompting the main agent just because a sub-agent is still in flight.

Additional Context

• Platform: macOS
• Product: Command code CLI
• Related/adjacent issue: #694 ("Allow subcommands to run during active session") covers running lightweight utility commands (e.g. /feedback, /model, /usage) while an agent is active — not accepting new task-level prompts or letting the main agent autonomously dispatch new sub-agents for them. This request is specifically about non-blocking prompting and agent-directed concurrency, not utility commands.
• The main agent, not the user, should own the decision of whether a new prompt becomes a new parallel sub-agent, gets queued behind existing work, or gets merged into an existing sub-agent's task — similar to how a shell scheduler/job control decides how backgrounded jobs coexist, rather than the user manually managing each process.

How important is this to you?

Important for my workflow

Nell’issue non sono identificati file, test o punti di ingresso. Inizia individuando la gestione di prompt/session della CLI e il ciclo di vita dei sub-agent, quindi definisci come devono comportarsi i concurrent prompts, il queued work e i background results; il lavoro è completato quando il main agent può accettare un nuovo prompt senza interrompere il lavoro esistente dei sub-agent.