OMO Harness Stream Consumer Deadlock: LLM stream hangs indefinitely

[easdkr]

Bug Description

The OMO harness stream consumer can deadlock indefinitely when an LLM provider stops emitting events but never closes the stream. This was observed with Kimi K2.6 in thinking mode, where the stream hung for 36 minutes until manually cancelled.

Reproduction Steps

1. Configure an agent to use Kimi K2.6 with variant "high" (thinking enabled)
2. Trigger a plan creation via task(subagent_type="plan", ...)
3. The stream starts but after some events, no more events are emitted
4. The stream consumer waits indefinitely with no timeout or error
5. After 36 minutes, the user must manually cancel the session

Expected Behavior

The stream should timeout if no events are received for a reasonable period (e.g., 5 minutes) and emit an error event to allow graceful degradation.

Actual Behavior

The stream consumer hangs forever, waiting for the next event that never arrives.

Environment

• OpenCode version: 1.16.2
• Provider: Kimi For Coding (kimi-k2.6)
• Variant: high (thinking enabled)
• OS: macOS

Root Cause

In packages/opencode/src/session/llm.ts, the AI SDK fullStream is converted to an Effect Stream without any timeout between events. When the provider stops emitting but doesn't close the stream, Stream.fromAsyncIterable waits forever.

Proposed Fix

Add Stream.timeout and Stream.catchCause to handle the timeout gracefully, ensuring the stream errors out after 5 minutes of inactivity instead of hanging indefinitely.

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Explore subagent hangs indefinitely with Anthropic Claude Opus 4.6 -- no timeout or recovery #13841: Same root cause — LLM stream hangs indefinitely with no timeout or recovery when the provider stops emitting chunks. Covers the same llm.ts stream idle timeout gap and proposes the same fix direction.
• [BUG] chunkTimeout does not work for AWS Bedrock and other non-SSE streaming protocols (EventStream) #26487: Related — chunkTimeout fails for non-SSE streaming protocols (AWS Bedrock/EventStream), which is another manifestation of the same missing stream-level timeout protection.

Please review those issues and consider whether this is already tracked there before proceeding.

[Davide95]

This is still happening on OpenCode 1.18.8 on macOS.

I observed streams remain open indefinitely after network/VPN interruptions. In some cases no response arrived; in another, one text chunk arrived and the stream then remained silent for 57 minutes. The OpenCode process stayed healthy, but there was no stream error, retry, or exiting loop log. Manual cancellation was required.

Clean TCP failures are retried correctly. The problem occurs when the connection becomes half-open and no error reaches OpenCode.

This has occurred across multiple providers, so it does not appear provider-specific. Foreground tasks also remain blocked indefinitely when the affected stream belongs to a subagent.

[Davide95]

Ciao @StarpTech! I have a PR that likely fix it, and I've already tested it with ~10 candidates, who reported it solves their issue. LMK if I can help in any way :)