Repository navigation
[FEATURE]: Add configurable timeout parameter to the Task tool #15080
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
The Task tool (used to dispatch subagents like explore and general) has no timeout parameter. Subagents can hang for 5–15+ minutes on tasks that should complete in 15–30 seconds, blocking the entire conversation with no way for the caller to recover programmatically.
The Bash tool already supports an optional timeout parameter (in milliseconds). The Task tool should have the same capability.
Proposed changes:
- Add an optional
timeoutparameter to the Task tool schema (milliseconds, consistent with Bash tool). - Set a reasonable default timeout (e.g., 120,000 ms / 2 minutes) when none is specified.
- On timeout, return a structured timeout error so the calling agent can fall back — retry with a smaller scope, do the work directly, or inform the user.
Why this matters:
- There is currently no workaround. The caller agent waits indefinitely and the user must manually abort.
- Codebases with AI rules (e.g., "set explicit timeout per request," "never wait indefinitely") cannot enforce those rules on Task tool calls because the parameter doesn't exist.
- This is distinct from the async/non-blocking dispatch request in Feature Request: Async Task Management - Non-blocking Subagent Dispatch #15069. That issue proposes a fundamentally different execution model. This request is narrower: just add a timeout so synchronous Task calls don't hang forever.
Note: Supersedes #15072, which was not created using the required feature request template.
Reacted by Artem Iagovdik, Georgy (George) Fedorov, Olaf Wagner and davtur19
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Feb 25, 2026
This issue might be a duplicate of existing issues. Please check:
jdocker8 commentedon Mar 25, 2026
Between this issue and the repeated summaries issue I opened #13838 there's a significant amount of time lost. I suggest tickets like these be given a higher priority since having issues like these so drastically reduce the usability and productivity with opencode. The difference between opencode and Codex (not the model but the cli/gui) in speed of completing work is drastically in Codex favor.
georgeglarson commentedon Apr 30, 2026
Want to take this. Deterministic repro across providers; PR shortly.
Repro: parallel
opencode runagainst ~10 models, same prompt. 8 return in 36s–7min;mimo/mimo-v2.5-proandminimax/MiniMax-M2.7spawn the Explore Agent subagent and never return. Pre-inlining the files referenced in the prompt (so the model has no reason to invoke Explore Agent) makes both complete in <5min. The hang is on the subagent → parent return path, not the model.This matches the broader pattern across #24669, #23296, #13841, #21250, #22252, #18378, #23891 — all converge on the same root:
tool/task.tsawaitsops.prompt(...)with no timeout, so any stall in the subagent path hangs the parent indefinitely.Approach (mirroring
bash.ts):timeout: number(ms) on the Task Parameters schema.OPENCODE_EXPERIMENTAL_TASK_DEFAULT_TIMEOUT_MSflag, default ~10 min.ops.prompt(...)againstEffect.sleep(timeout). On timeout:ops.cancel(nextSession.id)and return a<task_error>block with thetask_idso the caller can retry with a larger timeout, narrow the scope, or fall back.Please assign if no objections.
r-arteaga commentedon May 16, 2026
same issue here with an android kotlin project. 90% of the times build process completes and shows BUILD SUCCESSFUL in the logs but still sub agent hangs.
r-arteaga commentedon Jun 20, 2026
Quoting myself with a workaround
In agents.md I added an instruction to build using gradlew with --no-daemon flag.
github-actions commentedon Aug 20, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
fix(opencode): add configurable timeout to Task tool