anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Task Tool Timeouts & Early Termination in Multi-Agent Conductor Pattern #4143

New Issue
Open
opened 2026-02-16 17:42:46 -05:00 by yindo · 6 comments
yindo commented 2026-02-16 17:42:46 -05:00
Owner
Copy Link
Copy Source

Originally created by @DaveW001 on GitHub (Jan 3, 2026).

Originally assigned to: @rekram1-node on GitHub.

Question

Date: January 2, 2026
Environment: opencode Windows

Executive Summary

We are implementing a Multi-Agent "Conductor" Pattern where a primary agent orchestrates specialized sub-agents (Researcher, Writer) using the Task tool.

We are encountering a critical issue where tasks exceeding a short duration (~30-60s) return only a session_id string to the conductor, and the sub-agent session appears to terminate immediately, failing to complete the work (e.g., writing a file).

We have attempted to configure timeouts at the Provider and Agent level, but the behavior persists, suggesting a hardcoded timeout in the Task tool implementation or a signal handling issue that kills the child process.

1. Our Architecture

We are using the Conductor Pattern to keep context windows clean and enforce role separation.

Conductor (@content-factory):

  • Role: Orchestration only. Never writes content itself.
  • Action: Calls Task(subagent_type="researcher", prompt="...").
  • Expectation: Waits for sub-agent to finish and return a string (e.g., "Report saved to path/to/file.md").

Sub-Agents (@researcher, @writer):

  • Role: Execute heavy work (Search, Write 2k words).
  • Action: Use tools (perplexity-search, write), then return a string result.

The Workflow Attempted

// Conductor calls Researcher
task({
  subagent_type: "researcher",
  prompt: "Research 'Government IT Trends'. Use perplexity. Save report to 'research.md'. Return path.",
  description: "Deep Research"
})

2. The Issue

  • Behavior A: Short/Simple Tasks (Success)
  • Task: "Write 3 bullet points." (Pure generation, < 10s)
  • Result: The Task tool returns the actual string content.
  • Outcome: Success.

Behavior B: Medium/Complex Tasks (Failure)

  • Task: "Research X using Perplexity and write a report." (Tool use + Gen, > 60s)
  • Result: The Task tool returns a metadata block:
<task_metadata>
session_id: ses_47ddfbc5affe...
</task_metadata>
  • Critical Failure: The requested file (research.md) is NEVER created.
  • Implication: The sub-agent did not just "detach"; it stopped running entirely.

3. Debugging & Attempts

We performed extensive testing to isolate the cause.

Attempt 1: Global Provider Timeout
Hypothesis: The model provider is timing out. Action: Updated opencode.json with extreme timeouts:

"provider": {
  "openai": { "options": { "timeout": 600000 } } // 10 minutes
}

Result: No change. Long tasks still return session_id immediately after ~60s.

Attempt 2: Agent-Level Timeout
Hypothesis: The agent definition needs its own timeout. Action: Added timeout: 600000 to .opencode/agent/researcher.md. Result: No change.

Attempt 3: Permission Fixes
Hypothesis: Sub-agent crashed due to missing permissions. Action: Discovered @researcher lacked perplexity-search permission. Fixed it. Result: "Medium" tasks (Find 5 stats) started working! BUT, "Full Research" (running multiple searches sequentially) still fails with session_id only.

Attempt 4: "Fire and Forget" (Async Polling)
Hypothesis: Maybe the session_id return is "working as designed" (async), and we just need to wait. Action:

Conductor sends task: "Write a 500-word essay to test.md."
Task tool returns session_id.
Conductor waits 60 seconds (bash sleep 60).
Conductor checks for test.md. Result: File never appears. Conclusion: The sub-agent session is killed or suspended the moment the Task tool "times out" and returns the session ID. It does not continue in the background.

4. Workaround: Chunking

The only reliable solution we found is to artificially break tasks into micro-chunks (30-60s max):
"Find 5 stats" (Return)
"Find 3 examples" (Return)
"Write report using stats+examples" (Return)
This defeats the purpose of an autonomous "Deep Research" agent and forces the Conductor to micro-manage.

5. Request for Help

Is there a timeout parameter for the Task tool itself? (Client-side wait time).
Why does the sub-agent die? If the Conductor stops waiting, shouldn't the sub-agent session continue running on the server?
Is wait: true supported? We need a way to force the Task tool to wait indefinitely (or 10m+) for the sub-agent to finish.

Originally created by @DaveW001 on GitHub (Jan 3, 2026). Originally assigned to: @rekram1-node on GitHub. ### Question Date: January 2, 2026 Environment: opencode Windows ### Executive Summary We are implementing a Multi-Agent "Conductor" Pattern where a primary agent orchestrates specialized sub-agents (Researcher, Writer) using the Task tool. We are encountering a critical issue where tasks exceeding a short duration (~30-60s) return only a session_id string to the conductor, and the sub-agent session appears to terminate immediately, failing to complete the work (e.g., writing a file). We have attempted to configure timeouts at the Provider and Agent level, but the behavior persists, suggesting a hardcoded timeout in the Task tool implementation or a signal handling issue that kills the child process. ### 1. Our Architecture We are using the Conductor Pattern to keep context windows clean and enforce role separation. Conductor (@content-factory): - Role: Orchestration only. Never writes content itself. - Action: Calls Task(subagent_type="researcher", prompt="..."). - Expectation: Waits for sub-agent to finish and return a string (e.g., "Report saved to path/to/file.md"). Sub-Agents (@researcher, @writer): - Role: Execute heavy work (Search, Write 2k words). - Action: Use tools (perplexity-search, write), then return a string result. ### The Workflow Attempted ``` // Conductor calls Researcher task({ subagent_type: "researcher", prompt: "Research 'Government IT Trends'. Use perplexity. Save report to 'research.md'. Return path.", description: "Deep Research" }) ``` ### 2. The Issue - Behavior A: Short/Simple Tasks (Success) - Task: "Write 3 bullet points." (Pure generation, < 10s) - Result: The Task tool returns the actual string content. - Outcome: Success. Behavior B: Medium/Complex Tasks (Failure) - Task: "Research X using Perplexity and write a report." (Tool use + Gen, > 60s) - Result: The Task tool returns a metadata block: ``` <task_metadata> session_id: ses_47ddfbc5affe... </task_metadata> ``` - Critical Failure: The requested file (research.md) is NEVER created. - Implication: The sub-agent did not just "detach"; it stopped running entirely. ### 3. Debugging & Attempts We performed extensive testing to isolate the cause. Attempt 1: Global Provider Timeout Hypothesis: The model provider is timing out. Action: Updated opencode.json with extreme timeouts: ``` "provider": { "openai": { "options": { "timeout": 600000 } } // 10 minutes } ``` Result: No change. Long tasks still return session_id immediately after ~60s. Attempt 2: Agent-Level Timeout Hypothesis: The agent definition needs its own timeout. Action: Added timeout: 600000 to .opencode/agent/researcher.md. Result: No change. Attempt 3: Permission Fixes Hypothesis: Sub-agent crashed due to missing permissions. Action: Discovered @researcher lacked perplexity-search permission. Fixed it. Result: "Medium" tasks (Find 5 stats) started working! BUT, "Full Research" (running multiple searches sequentially) still fails with session_id only. Attempt 4: "Fire and Forget" (Async Polling) Hypothesis: Maybe the session_id return is "working as designed" (async), and we just need to wait. Action: Conductor sends task: "Write a 500-word essay to test.md." Task tool returns session_id. Conductor waits 60 seconds (bash sleep 60). Conductor checks for test.md. Result: File never appears. Conclusion: The sub-agent session is killed or suspended the moment the Task tool "times out" and returns the session ID. It does not continue in the background. ### 4. Workaround: Chunking The only reliable solution we found is to artificially break tasks into micro-chunks (30-60s max): "Find 5 stats" (Return) "Find 3 examples" (Return) "Write report using stats+examples" (Return) This defeats the purpose of an autonomous "Deep Research" agent and forces the Conductor to micro-manage. ### 5. Request for Help Is there a timeout parameter for the Task tool itself? (Client-side wait time). Why does the sub-agent die? If the Conductor stops waiting, shouldn't the sub-agent session continue running on the server? Is wait: true supported? We need a way to force the Task tool to wait indefinitely (or 10m+) for the sub-agent to finish.
yindo added the windows label 2026-02-16 17:42:46 -05:00
yindo commented 2026-02-16 17:42:46 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 3, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #5887: [feat] True Async/Background Sub-Agent Delegation - Addresses the exact same core problem of sub-agents terminating prematurely and the need for non-blocking async delegation
  • #6651: [FEATURE]: Dynamic model selection for subagents via Task tool - Related to Task tool enhancements for better subagent control
  • #1721: bash tool often times out - Documents the underlying timeout issue affecting long-running operations (same root cause)
  • #3950: [FEATURE]: Configurable command timeout in config.json - Requests configurable timeouts to extend execution duration

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 3, 2026): This issue might be a duplicate of existing issues. Please check: - #5887: [feat] True Async/Background Sub-Agent Delegation - Addresses the exact same core problem of sub-agents terminating prematurely and the need for non-blocking async delegation - #6651: [FEATURE]: Dynamic model selection for subagents via Task tool - Related to Task tool enhancements for better subagent control - #1721: bash tool often times out - Documents the underlying timeout issue affecting long-running operations (same root cause) - #3950: [FEATURE]: Configurable command timeout in config.json - Requests configurable timeouts to extend execution duration Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:42:46 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Jan 3, 2026):

hm can u share examples of this happening? example configs maybe?

@rekram1-node commented on GitHub (Jan 3, 2026): hm can u share examples of this happening? example configs maybe?
yindo commented 2026-02-16 17:42:46 -05:00
Author
Owner
Copy Link
Copy Source

@DaveW001 commented on GitHub (Jan 3, 2026):

Yes. Please see attached. If there is something you need that isn't here, let me know what and where to find it. It is possible I've don't something wrong. This is my first attempt to use sub-agents.

opencode-troubleshooting.tar.gz

@DaveW001 commented on GitHub (Jan 3, 2026): Yes. Please see attached. If there is something you need that isn't here, let me know what and where to find it. It is possible I've don't something wrong. This is my first attempt to use sub-agents. [opencode-troubleshooting.tar.gz](https://github.com/user-attachments/files/24419806/opencode-troubleshooting.tar.gz)
yindo commented 2026-02-16 17:42:46 -05:00
Author
Owner
Copy Link
Copy Source

@moonray commented on GitHub (Jan 19, 2026):

I'm seeing similar results

example (this happens intermittently):
orchestrator agent (primary) starts task for archiver agent
archiver agent completes steps 1-4 but never starts on step 5; orchestrator shows it's still waiting for task to complete, but when looking at archiver, it seems stuck right before starting on step 5

what I'd love to see is (probably not for this issue, but adding for reference):

  • a way to see if the the task is still progressing (is it waiting for llm to return a response or something else?) or whatever it's doing, and how long it's been doing it, or if it considers itself done with its task
  • a progress "spinner" on the task view itself when it's sending data to the model or waiting for the model to return a response
  • perhaps a new tab in the console to see details of task or agent in addition to the very basic logs it currently outputs

I don't know if I would need a per-task timeout setting, but at least a global timeout setting for tasks so control would return to the parent agent, telling it that something happened that cause a timeout, allowing it to either retry, throw it back at the user, or anything really. 😁

@moonray commented on GitHub (Jan 19, 2026): I'm seeing similar results example (this happens intermittently): orchestrator agent (primary) starts task for archiver agent archiver agent completes steps 1-4 but never starts on step 5; orchestrator shows it's still waiting for task to complete, but when looking at archiver, it seems stuck right before starting on step 5 what I'd love to see is (probably not for this issue, but adding for reference): - a way to see if the the task is still progressing (is it waiting for llm to return a response or something else?) or whatever it's doing, and how long it's been doing it, or if it considers itself done with its task - a progress "spinner" on the task view itself when it's sending data to the model or waiting for the model to return a response - perhaps a new tab in the console to see details of task or agent in addition to the very basic logs it currently outputs I don't know if I would need a per-task timeout setting, but at least a global timeout setting for tasks so control would return to the parent agent, telling it that something happened that cause a timeout, allowing it to either retry, throw it back at the user, or anything really. 😁
yindo commented 2026-02-16 17:42:47 -05:00
Author
Owner
Copy Link
Copy Source

@dcominottim commented on GitHub (Feb 2, 2026):

I'm seeing similar results

example (this happens intermittently): orchestrator agent (primary) starts task for archiver agent archiver agent completes steps 1-4 but never starts on step 5; orchestrator shows it's still waiting for task to complete, but when looking at archiver, it seems stuck right before starting on step 5

what I'd love to see is (probably not for this issue, but adding for reference):

  • a way to see if the the task is still progressing (is it waiting for llm to return a response or something else?) or whatever it's doing, and how long it's been doing it, or if it considers itself done with its task
  • a progress "spinner" on the task view itself when it's sending data to the model or waiting for the model to return a response
  • perhaps a new tab in the console to see details of task or agent in addition to the very basic logs it currently outputs

I don't know if I would need a per-task timeout setting, but at least a global timeout setting for tasks so control would return to the parent agent, telling it that something happened that cause a timeout, allowing it to either retry, throw it back at the user, or anything really. 😁

opencode really needs some kind of sane timeout with automatic retries for tasks/subagents. When using Codex / OpenAI, my subagents are frequently getting stuck and apparently there's indeed no kind of timeout or retry whatsoever.

Image
@dcominottim commented on GitHub (Feb 2, 2026): > I'm seeing similar results > > example (this happens intermittently): orchestrator agent (primary) starts task for archiver agent archiver agent completes steps 1-4 but never starts on step 5; orchestrator shows it's still waiting for task to complete, but when looking at archiver, it seems stuck right before starting on step 5 > > what I'd love to see is (probably not for this issue, but adding for reference): > > * a way to see if the the task is still progressing (is it waiting for llm to return a response or something else?) or whatever it's doing, and how long it's been doing it, or if it considers itself done with its task > * a progress "spinner" on the task view itself when it's sending data to the model or waiting for the model to return a response > * perhaps a new tab in the console to see details of task or agent in addition to the very basic logs it currently outputs > > I don't know if I would need a per-task timeout setting, but at least a global timeout setting for tasks so control would return to the parent agent, telling it that something happened that cause a timeout, allowing it to either retry, throw it back at the user, or anything really. 😁 opencode really needs some kind of sane timeout with automatic retries for tasks/subagents. When using Codex / OpenAI, my subagents are frequently getting stuck and apparently there's indeed no kind of timeout or retry whatsoever. <img width="1585" height="1126" alt="Image" src="https://github.com/user-attachments/assets/5e5ea197-f047-4142-8671-cc2cef24e7bb" />
yindo commented 2026-02-16 17:42:47 -05:00
Author
Owner
Copy Link
Copy Source

@sbluemin commented on GitHub (Feb 11, 2026):

My subagent also occasionally fails to process requests and becomes a zombie agent. I desperately need a timeout feature.

@sbluemin commented on GitHub (Feb 11, 2026): My subagent also occasionally fails to process requests and becomes a zombie agent. I desperately need a timeout feature.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label windows
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4143
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?