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

O issue não identifica arquivos, testes ou pontos de entrada. Comece localizando o tratamento de prompt/session da CLI e o ciclo de vida dos sub-agents; em seguida, defina como concurrent prompts, queued work e background results devem se comportar; considera-se concluído quando o main agent puder aceitar um novo prompt sem interromper o trabalho existente dos sub-agents.

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