Allow prompting the main agent while sub-agents are actively working (background sub-agent execution)
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Anfängerfreundlichkeit
- 35/100
Rechercherichtung
Im Issue sind keine Dateien, Tests oder Einstiegspunkte angegeben. Beginne damit, die prompt/session-Verarbeitung der CLI und den sub-agent-Lebenszyklus zu lokalisieren, und definiere anschließend, wie concurrent prompts, queued work und background results sich verhalten sollen; die Aufgabe ist erledigt, wenn der main agent einen neuen prompt akzeptieren kann, ohne die bestehende sub-agent-Arbeit zu stoppen.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
- Vorherrschende Sprache
- Keine Sprachdaten
- Sterne
- 4k
- Forks
- 350
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Beitragsleitfaden
Für dieses Repository ist kein Beitragsleitfaden indexiert
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus CommandCodeAI/command-code
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
CommandCodeAI/command-code#903 · 2 Kommentare ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
CommandCodeAI/command-code#855 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
CommandCodeAI/command-code#841 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
CommandCodeAI/command-code#655 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
CommandCodeAI/command-code#608 ·
Alle Issues in CommandCodeAI/command-code
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
run-llama/llama_index#23199 ·
-
p:2-high pydanty:bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 90/100
pydantic/pydantic-ai#8642 · 2 Kommentare ·
-
bug untriaged
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
opensearch-project/ml-commons#5094 ·
-
bug external groq
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
langchain-ai/langchain#40771 · 1 Kommentar ·
-
ai-observability bug team/ai-observability
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100