Repository navigation
Feature: per-subagent timeout / tool-call budget — one stalled child hangs the parent indefinitely #46461
Description
Problem
A task that spawns subagents has no per-child wall-clock timeout or budget: when one subagent stalls (e.g. its model backend stops responding mid-call), the parent waits forever with no error and no recovery.
Measured case (OpenCode 1.18.x, Windows 11, local Ollama models via an OpenAI-compatible provider): an unattended research task spawned several subagents; one child's backend stalled and the parent hung 20 minutes until manually killed. The identical task re-run with a prompt-level instruction ("at most N tool calls, then report") completed in 169 s with full results — so the work itself was fine; only the missing guardrail made the run unsafe.
Related open reports that look like the same missing guardrail from different angles: #33028 (subagents hang indefinitely, stream never times out), #13841 (Explore subagent hangs, no timeout or recovery), #44931 (background subagents hang silently on repeated upstream 429s).
Proposal
- A configurable per-subagent wall-clock timeout (config default + per-agent override), after which the child is cancelled and the parent receives a structured "subagent timed out" result it can act on.
- Optionally a tool-call budget per subagent as a second, cheaper guardrail (deterministic, model-independent).
Prompt discipline works as a workaround but shouldn't be the only line of defense for unattended runs — a stalled child currently converts into an unbounded parent hang.
Activity
johnmwhitman commentedon Sep 26, 2026
This won't fix the native task tool, but here's a workaround in the meantime. I maintain MeshFleet (https://github.com/johnmwhitman/agent-mesh), an MCP server that runs each agent as its own OS process. Every run has a hard timeout: SIGTERM, then SIGKILL of the process group after a grace period.
set_fleet_timeoutsets that per fleet, so a stalled child is marked failed and reported instead of holding the parent open.It covers the timeout half of this request, not a per-agent tool-call budget.
npx -y meshfleetif you want to try it. Happy to answer questions here.opencodejr commentedon Oct 28, 2026
Thanks for the detailed write-up and the measurements, @bojan-ilijevski!
This was measured on OpenCode 1.18.x, which is v1. v1 only gets fixes for critical bugs such as data loss, security problems or breakage with no workaround, so this request is unlikely to be picked up there. You also already have a workaround with the prompt-level tool-call cap.
We'd encourage you to try v2 (
@opencode/cli, theopencodecommand). On the budget side, v2 agents accept astepsoption in their agent config, which limits how many steps an agent (including a subagent) can take. v2 has no per-subagent wall-clock timeout yet. Related v2 issues and PRs on stalled streams and steps:If you see the same unbounded parent hang on v2, or you think this is critical, please reply here with the v2 version and details.
opencodejr commentedon Oct 29, 2026
Closing this as not planned. The report is about OpenCode v1 (1.18.x), which only gets critical fixes, and there's a working workaround (the prompt-level tool-call cap). We haven't heard that this also happens on v2.
On v2, agents accept a
stepsoption that limits how many steps a subagent can take. Work on stalled streams and steps that never time out is tracked in #53747, #59872 and #59565.If you see a stalled subagent hang the parent on v2, please open a new issue with the v2 version and details, or reply here. Thanks again for the detailed report!