Subagent stream error can surface as empty task result

Summary

When a subagent provider stream fails, the TUI briefly shows that something went wrong, but the parent/model-facing task result can be returned as an empty successful-looking <task_result></task_result> instead of surfacing the error.

This is easy for a human to miss in the TUI and invisible to the model unless it independently inspects opencode.log. In my case the model almost treated the empty result as a valid no-findings subagent critique.

Version

opencode 1.18.3

What Happened

I invoked a configured runner subagent for a critique task. The task result returned to the parent was empty:

<task_result>

</task_result>

The TUI briefly indicated that something went wrong, but the parent agent did not receive an error. Only after checking logs did I find the underlying stream failure.

Relevant log excerpt:

timestamp=2026-07-25T14:22:27.925Z level=INFO run=ef03df89 message=created id=ses_066580fabffe9rLDtPVEYMqlNm title="Critique v6 repair (@runner subagent)" agent=runner ...
timestamp=2026-07-25T14:22:28.115Z level=INFO run=ef03df89 message=stream providerID=opencode modelID=nemotron-3-ultra-free session.id=ses_066580fabffe9rLDtPVEYMqlNm small=false agent=runner mode=subagent
timestamp=2026-07-25T14:22:30.608Z level=ERROR run=ef03df89 message="stream error" providerID=opencode modelID=nemotron-3-ultra-free session.id=ses_066580fabffe9rLDtPVEYMqlNm small=false agent=runner mode=subagent error.error="Streaming response failed"
timestamp=2026-07-25T14:22:30.620Z level=ERROR run=ef03df89 message=process session.id=ses_066580fabffe9rLDtPVEYMqlNm messageID=msg_f99a7f0990010ilbmULzVtOSdd error="Streaming response failed" stack=undefined

Expected Behavior

If a subagent stream fails, the parent task call should surface a hard failure, for example:

Task failed: subagent stream error: Streaming response failed

The model-facing result should not be an empty task result that can be mistaken for successful completion.

Why This Matters

Subagents are often used for critique, evidence gathering, or safety checks. An empty result from a failed subagent can be misinterpreted as:

• no blockers found
• no findings
• task completed with no output

That can cause the parent agent to continue after a failed review step. The only indication may be a transient TUI message and a log entry the model does not automatically see.

Reproduction Notes

The stream failure itself appears intermittent/provider-side. The same configured subagent/model later completed several controlled probes successfully:

• tiny response task
• file-read task
• critique-shaped task
• retry of the original critique task
• three parallel stress probes

So the issue is not that the model ID is categorically invalid. The important bug is that the failed subagent stream was converted into an empty parent-visible task result instead of a failed task.

Suggested Fix

• Propagate subagent stream/process errors to the parent task result as explicit failures.
• Never return an empty successful-looking <task_result> for a failed subagent stream.
• Consider preserving the subagent session ID and provider/model/error text in the parent-visible failure.
• Optionally make the TUI error persistent enough that it cannot be missed.