Repository navigation
[FEATURE]: UI should indicate when streaming connection is lost/interrupted #15393
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
When the WiFi connection has packet loss (even temporarily), streaming HTTP connections to the LLM provider stall silently. The UI shows no indication that anything is wrong and the agent chat hangs indefinitely with no error, timeout message, or retry prompt.
Using mtr I confirmed 60–80% packet loss between my machine and router during these hang events. The underlying network issue is on my end, but the OpenCode UI gives no feedback that the stream has stalled.
Expected behavior:
Display a message like "Connection interrupted" when the stream stalls for more than N seconds
Or surface a timeout error with an option to retry rather than hanging silently
The ideal fix would be to better handle streaming loss (see #8002) , but I think the best first step would just be detecting the loss and displaying a message. Currently, the "thinking" indicator keeps bouncing back and forth so I don't know if the provider is just taking its sweet time or if the connection dropped.
Update: the bot identified a few other issues that are related but asking for more thorough fixes, this request is just for a minor UI update in the meantime
Activity
github-actions commentedon Feb 27, 2026
This issue might be a duplicate of existing issues. Please check:
Your issue specifically focuses on the UI feedback aspect (showing a "Connection interrupted" message), which is a distinct angle worth keeping if the above issues don't cover it.
github-actions commentedon Apr 29, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
IceTea233 commentedon Jun 9, 2026
Definitely need this. Work with OpenCode under unstable network environment becomes really frustrating. I need to frequently wait for a stall response for couples of minutes, then manually interrupt it.
Surely a proper recovery is much better, but this seems to be relatively simple and already good enough for diagnosing the problem.