Subtask hangs silently forever when ripgrep download stalls on first run #23891

Summary

On first run in a fresh WSL2 environment (no system rg installed), opencode
attempts to download its bundled ripgrep binary from GitHub Releases. When that
download stalls or fails, every built-in tool that relies on ripgrep
(grep, and the file sampling inside the skill tool) hangs indefinitely with
no error, no timeout, and no UI feedback. As a result, any subagent that
triggers a grep call (e.g. the explore subagent) appears frozen forever.
From the user's perspective opencode simply "stops working" after the first
subtask — there is no indication that a background binary download is the root
cause.

What happened

1. Installed opencode 1.14.20 fresh on WSL2. which rg → command not found.
2. Same version works fine on macOS (where I had rg previously cached / installed).
3. First non-trivial prompt in plan mode triggered an explore subagent.
4. The subagent showed ↳ 3 toolcalls (1× Grep, 2× Glob) and then froze.
5. Waited 8+ minutes. No progress, no error, no spinner change, nothing.

Log evidence

From ~/.local/share/opencode/log/<timestamp>.log (full log available on request):
Line 54 service=ripgrep url=https://github.com/BurntSushi/ripgrep/releases/download/15.1.0/ripgrep-15.1.0-x86_64-unknown-linux-musl.tar.gz downloading ripgrep
...
Line 548 service=llm ... agent=explore mode=subagent stream
Line 558 service=permission permission=grep pattern=image.(generat|tool)|generat.image action=allow
Line 562 service=permission permission=glob pattern=/imagetool*.ts action=allow
Line 566 service=permission permission=glob pattern=/tool//.ts action=allow
Line 587 +497497ms <-- 8 minutes of total silence, only TUI heartbeat GETs afterwards
Key observations:

• The downloading ripgrep log line (line 54) has no corresponding
  "downloaded" / "extracted" / "installed" log line anywhere in the file.
• The Grep tool was invoked (line 558) and permission was granted, but it
  never produced a completion log entry.
• The subagent, and therefore the parent session's TaskTool, is stuck
  awaiting a Promise that will never resolve.

Root cause (from reading the source)

Three compounding issues in opencode:

1. Ripgrep download has no timeout and no fallback. If the GitHub Releases
   CDN is slow or blocked (common in regions with restricted connectivity),
   the download Promise stays pending forever.
2. Grep / skill tools do not fall back to system rg even when one is
   available on $PATH. They only use the bundled download.
3. TaskTool in packages/opencode/src/tool/task.ts has no timeout or
   liveness check. It only wires an AbortController. A frozen child
   session freezes the parent indefinitely.

Expected behaviour

• Built-in tools (grep, glob, read, etc.) should refuse to run and
  return a descriptive error immediately if their required binary is not
  yet available, instead of silently awaiting it.
• TaskTool should provide a "no activity for N seconds" warning in the TUI
  so users can see something is wrong.

Why a good UI hint matters

Built-in tools like grep are part of the core UX promise — users assume
they "just work" after install. When they silently hang on first run, there
is no signal a user can act on:

• No error message
• No progress bar for the background download
• No hint to install ripgrep manually
• Subtask UI just shows a static ↳ 3 toolcalls forever
  A simple status line such as
  "Downloading ripgrep (15.1.0)... 40% – grep is temporarily unavailable"
  or, on failure,
  "Failed to download ripgrep. Please install it via your package manager (e.g. 'sudo apt install ripgrep') and restart opencode."
  would have saved hours of debugging and avoided a "the product is broken"
  impression for a new user.

Workaround

Installing system ripgrep and restarting opencode resolves the symptom:

sudo apt install ripgrep
But this only works if the user somehow figures out that ripgrep is the
culprit — which is the point of this issue.
Environment
- OpenCode version: 1.14.20
- OS: WSL2 (Ubuntu) on Windows 11
- Terminal: <fill in your actual terminal, e.g. Windows Terminal>
- Plugins: none
- Works fine on: macOS 26 with same opencode version
Suggested fixes (in priority order)
1. Add a startup readiness check for each built-in tool's required
   binaries; if a binary is missing, mark the tool as unavailable with a
   clear message instead of letting calls hang.
2. Add a generic "no activity" warning to TaskTool after N seconds so
   users can tell when a subtask is stuck.

### Plugins

_No response_

### OpenCode version

1.14.20

### Steps to reproduce

1. Do **not** install ripgrep
   (`sudo apt remove ripgrep` if present).
2. Block or throttle access to `github.com` release downloads to simulate a
   slow/failed download (or simply try from a network where this is the case).
3. Install opencode `1.14.20` and launch in any project.
4. Ask it something that triggers an `explore` subagent, e.g.
   `"Analyze how tool X is implemented in this codebase"`.
5. Observe: subagent shows 3 toolcalls, then hangs forever with no error.

### Screenshot and/or share link

_No response_

### Operating System

Window 11

### Terminal

Windows Terminal