1.2.25 subagent/task calls can hang at 0 messages after createUserMessage schema validation failure #17387

Description

On opencode 1.2.25, subagent/task invocations in our environment could stay at 0 messages and never complete. The visible failure in the TUI was a createUserMessage schema validation failure. Nothing equally useful was written to the log files, so the run looked like a hang unless you saw the TUI stack trace.

Downgrading off 1.2.25 immediately resolved the problem. After downgrade, the same smoke tests succeeded again (metis, explore, librarian all completed normally).

This looks distinct from #16841: that issue is about console.trace() corrupting the TUI during schema validation failures; this issue is about the underlying subagent/task call getting stuck after the validation failure.

What we observed

• subagent/task invocations stayed in a running state with 0 messages
• the only useful clue was a TUI stack trace mentioning createUserMessage schema validation failure
• normal log files did not capture the root cause clearly
• downgrading off 1.2.25 fixed the issue immediately

Steps to reproduce

1. Install opencode 1.2.25
2. Trigger subagent/task dispatches repeatedly
3. Observe one of the invocations get stuck at 0 messages / never complete
4. In the TUI, a createUserMessage schema validation failure appears
5. Downgrade opencode and rerun the same smoke tests; they complete successfully

Environment

• OpenCode version: 1.2.25
• OS: Linux (WSL2)
• Observed during subagent/task dispatches (metis / explore / librarian in our setup)
• Backend in this environment was an OpenAI-compatible local proxy, but the visible failure point was inside opencode message creation / validation

Expected behavior

A schema validation failure in createUserMessage should not leave the subagent/task invocation stuck at 0 messages. The invocation should fail cleanly with a surfaced error, and logs should make the root cause visible.

Actual behavior

The invocation appears to hang at 0 messages, and the useful diagnostic is only visible in the TUI stack trace. Downgrading avoids the problem.