Description
When an agent dispatches multiple sub-agents in parallel via task(), and one sub-agent gets stuck or fails, the opencode runtime currently aborts ALL sub-agents — including those that completed successfully. This means that in a batch of 5 parallel sub-agent calls, if 4 succeed and 1 times out, the 4 successful results are lost.
Steps to reproduce
- Create an agent that dispatches 3+ sub-agents in parallel via
task(subagent_type="...")
- Arrange for one sub-agent to get stuck (e.g., recursive exploration loop, unavailable tool)
- Wait for the stuck sub-agent to trigger a timeout/abort
- Observe that ALL sub-agents are terminated — even those that completed successfully
Evidence
From a production opencode deployment, session ses_0dab015c2:
- FDR dispatched 5 sub-agents in parallel: 4 explore + 1 scientific-paper-research
- 2 completed successfully (explore-2 returned findings, SPR returned paper data)
- 3 got stuck (explore children in recursive exploration loops)
- After 5.7 hours, the runtime aborted all 5 — even the 2 successful ones
- Total loss: 176K tokens of completed work discarded
More broadly, 5 mass-abort events observed where 3+ sub-agents were terminated together:
ses_10049ce8: 4 children aborted (3 completed, 1 stuck)ses_0d4228cd: 3 children abortedses_0dab015c2: 3 children aborted- etc.
Expected behavior
-
Independent sub-agent lifecycle: Each sub-agent should have its own success/failure/timeout status. When the parent collects results, it should receive:
completed results from successful sub-agentserror + reason from failed sub-agentstimeout from timed-out sub-agents
-
Partial results delivery: The parent agent should be able to proceed with partial results rather than losing everything when one sub-agent fails.
-
Per-subagent error isolation: A failure in one sub-agent should not cascade to abort sibling sub-agents.
Impact
This is critical for multi-agent orchestrator patterns where parallel sub-agent delegation is the normal mode of operation. Currently, the reliability of parallel delegation is bounded by the worst-performing sub-agent, not the best.
Description
When an agent dispatches multiple sub-agents in parallel via
task(), and one sub-agent gets stuck or fails, the opencode runtime currently aborts ALL sub-agents — including those that completed successfully. This means that in a batch of 5 parallel sub-agent calls, if 4 succeed and 1 times out, the 4 successful results are lost.Steps to reproduce
task(subagent_type="...")Evidence
From a production opencode deployment, session
ses_0dab015c2:More broadly, 5 mass-abort events observed where 3+ sub-agents were terminated together:
ses_10049ce8: 4 children aborted (3 completed, 1 stuck)ses_0d4228cd: 3 children abortedses_0dab015c2: 3 children abortedExpected behavior
Independent sub-agent lifecycle: Each sub-agent should have its own success/failure/timeout status. When the parent collects results, it should receive:
completedresults from successful sub-agentserror+ reason from failed sub-agentstimeoutfrom timed-out sub-agentsPartial results delivery: The parent agent should be able to proceed with partial results rather than losing everything when one sub-agent fails.
Per-subagent error isolation: A failure in one sub-agent should not cascade to abort sibling sub-agents.
Impact
This is critical for multi-agent orchestrator patterns where parallel sub-agent delegation is the normal mode of operation. Currently, the reliability of parallel delegation is bounded by the worst-performing sub-agent, not the best.