subagent: background subagents hang silently on repeated upstream 429s; no error or completion notification surfaces

Summary

A subagent tool call launched with background: true never reports anything when its child-session model requests start failing (repeated upstream HTTP 429 from a rate-limited provider subscription). The parent session keeps running normally, the promised automatic "finished" notification never arrives, and the TUI shows nothing wrong. The only way to discover the state is to interrupt the whole session, after which the subagent finally surfaces as cancelled. Meanwhile retries keep burning the already-exhausted quota.

Environment

• opencode version: 0.0.0-next-17403
• OS: Linux 6.18.33.2-microsoft-standard-WSL2 (Ubuntu 24.04, WSL2), x86_64
• Terminal: VS Code integrated terminal (TERM_PROGRAM=vscode, TERM=xterm-256color, COLORTERM=truecolor)
• Shell: /bin/bash
• Install/channel: next (mise-managed npm install)
• Active plugins: one project plugin path configured at reproduction time (~/.local-external directory that had been deleted); it fails to load with Cannot find module ... in the server log and is unrelated to this report. No other plugins.

Reproduction

1. Use a model provider routed through a free/rate-limited subscription so parallel or sustained requests trigger upstream HTTP 429 responses.
2. In a normal session, ask the primary agent to explore something read-only via the subagent tool with background: true (agent type explore).
3. The child session's model calls hit repeated 429s.
4. Keep working in the parent and ask it what the subagent is doing — it cannot answer; no status, error, or completion event is ever delivered to the parent or shown in the TUI.
5. Press Esc / interrupt the session.
6. Only now does a notice appear that the subagent ended, with state cancelled.

Expected Behavior

• A background subagent whose upstream requests fail should surface that failure promptly: a terminal error/part result event to the parent session plus a visible indicator in the TUI.
• The automatic "you will be notified when it finishes" contract should also hold on the failure path, not only on success.
• Ideally the runner applies bounded retry/backoff for transient 429s and then reports a distinguishable terminal state (e.g. failed: rate limited) instead of leaving the child in an indefinite in-progress limbo.

Actual Behavior

• The child session stalls indefinitely; no event, notification, or TUI change indicates a problem.
• The parent agent cannot answer questions about subagent progress ("what's the subagent doing?" got no useful answer for many minutes).
• Retries against the rate-limited provider continue silently, consuming more of the exhausted quota.
• After a manual interrupt, the subagent is reported only as cancelled (session id prefix ses_fc8036a7… in that run; parent ses_fc817cb3…). Nothing in the visible UI hinted at the 429 cause; it had to be inferred from the provider dashboard.

Additional Context

• Frequency: reproduced consistently within one long session whenever the upstream subscription was rate-limited; two different routed providers exhibited the same silent-hang behavior, which is why it looks like a runner-level gap rather than a provider adapter bug.
• Workaround: avoid background: true for subagents while on a rate-limited plan and run exploration inline in the primary agent, or interrupt the session to reclaim control and re-dispatch.
• Happy to pull the exact server-log lines (role=server, child session run ids) from ~/.local/share/opencode/log/opencode.log for the affected timeframe if useful — say the word and I'll attach a redacted excerpt.