Allow prompting the main agent while sub-agents are actively working (background sub-agent execution)
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
No files, tests, or entry points are identified in the issue. Start by locating the CLI's prompt/session handling and sub-agent lifecycle, then define how concurrent prompts, queued work, and background results should behave; done requires the main agent to accept a new prompt without stopping existing sub-agent work.
Written by the indexing model from the issue text.
Description
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
- Dominant language
- No language data
- Stars
- 4k
- Forks
- 350
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CommandCodeAI/command-code
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CommandCodeAI/command-code#903 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CommandCodeAI/command-code#855 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
CommandCodeAI/command-code#841 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CommandCodeAI/command-code#655 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
CommandCodeAI/command-code#608 ·
All issues in CommandCodeAI/command-code
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
run-llama/llama_index#23199 ·
-
p:2-high pydanty:bug
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
pydantic/pydantic-ai#8642 · 2 comments ·
-
bug untriaged
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
opensearch-project/ml-commons#5094 ·
-
bug external groq
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
langchain-ai/langchain#40771 · 1 comment ·
-
ai-observability bug team/ai-observability
Difficulty 2/5 1-3 hours Newbie friendliness 78/100