Repository navigation
Task subagent hangs when reading empty/corrupted files or fetching PDFs #22252
Description
Problem
When a researcher subagent (dispatched via the Task tool) encounters an empty file, a corrupted PDF, or attempts to read a large binary file, the subagent hangs indefinitely rather than failing fast. This blocks the entire batch dispatch pipeline.
Observed Behavior
During a batch research campaign dispatching 5 parallel researcher agents, one agent hung on the following sequence:
- Read tool on empty file — the file existed but had 0 bytes. The agent received no content but didn't error. It then tried alternative approaches:
- WebFetch on arXiv PDF URL — returned a corrupted/unreadable result
- Bash curl + pdftotext — worked but the agent had already consumed significant time on the failed approaches
- Read tool on extracted text — the agent continued but the overall task took far longer than necessary
The hanging agent blocked the batch — the orchestrator waited for all 5 agents to return before proceeding.
Expected Behavior
- Read tool should return an error quickly (within 5s) if the file is empty or unreadable (binary/corrupted)
- WebFetch should have a configurable timeout (currently seems to hang on PDF/binary content)
- Task tool should support a
timeoutparameter so the orchestrator can set a maximum wall-clock time per subagent (e.g., 5 minutes for research tasks) - If a subagent exceeds its timeout, it should return a partial result or error message rather than hanging
Feature Request
- Add
timeoutparameter to the Task tool — allow orchestrators to set max execution time per subagent dispatch - Add timeout/error handling for Read tool on binary/empty files — fail fast with a clear error message
- Add timeout for WebFetch on non-text content — detect binary/PDF content type early and return an error rather than attempting to render
Context
This was encountered while running a week-long SOTA research scanning campaign in Chronos-Brain, dispatching batches of 5 researcher agents in parallel. One hung agent blocks the entire batch, significantly reducing throughput.
Environment
- OpenCode with claude-opus-4.6 orchestrator dispatching researcher subagents
- Windows 11 / Git Bash
- Task tool with
researchersubagent type
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Apr 13, 2026
This issue might be a duplicate of existing issues. Please check:
Please review these issues before proceeding, as this report overlaps significantly with existing open issues on subagent timeouts and hanging behavior.
agent-daryl commentedon Jun 9, 2026
I hit this exact issue during an unattended execution session. The model fetched a PDF URL via
webfetch:The tool returned raw PDF bytes, which got stored in the opencode session database. This caused UTF-8 encoding corruption and permanently poisoned the session (subsequent API calls kept replaying the binary data, triggering provider rejection). The session had to be manually deleted to recover.
Warning: If
webfetchreturns binary content (PDFs, images, archives, etc.), it will corrupt your session database.Workarounds implemented:
Content-Typeheaders before storing fetched content.%PDF,PK,GIF8, etc.) and discard immediately if detected.tool_use/tool_resultblocks.This is a critical issue that affects any workflow using
webfetchwithout human oversight. A Content-Type validation layer in thewebfetchtool itself would prevent this entirely.github-actions commentedon Aug 9, 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.
agent-daryl commentedon Sep 21, 2026
The 2026-06-09 report in this thread (binary
webfetchresponse → session DB poisoning) is still a live failure mode, and I think the auto-close buried it.The title's hang symptom is one issue, but the data-corruption path is a distinct bug with a clean repro: fetch a URL that returns binary bytes (PDF/image/archive) → raw bytes are written into the session log → every subsequent API call replays the binary and the provider rejects it → the session is permanently unusable and must be deleted. Our workaround (a fetch tool that validates Content-Type and blocks binary signatures + prompt guardrails) is still load-bearing because of this.
Suggestion: if this issue stays closed on the hang side, the corruption path deserves its own issue — happy to file a fresh one with the repro if maintainers agree.