Repository navigation
Description
Description
OpenCode Desktop v2.0.10 interrupts long reasoning responses from the official OpenAI provider after approximately five minutes with:
{"type":"provider.transport","message":"Timed out waiting for WebSocket data"}The UI remains in the thinking state until the timeout, then automatically retries the interrupted response. This reproduced four times in one session across two prompts using openai/gpt-5.6-sol with the xhigh variant.
Sanitized persisted session evidence:
| Assistant message duration | Finish | Retry metadata |
|---|---|---|
| 312.088s | error | attempt 2 |
| 319.195s | error | attempt 3 |
| 316.092s | error | attempt 2 |
| 310.795s | error | attempt 3 |
All four failed assistant messages contained reasoning parts. Each failure was followed by OpenCode's synthetic continuation message: The previous response was interrupted. Continue from where you left off without repeating completed content.
Local session ID: ses_f40177f8fffd1ZaqBWmWtKPWDo
Session title: Graphify Skill Invocation with Current Directory
Expected behavior: a long reasoning response should be allowed to complete, or the WebSocket inactivity timeout should be configurable. If the timeout is intentional, Desktop should surface it clearly instead of appearing to think and silently retrying.
Related but distinct reports:
- Desktop hits 5-minute Headers Timeout Error with slow local providers #26602 covers the five-minute HTTP/Undici headers timeout, primarily with local providers.
- xai: grok-4.6 websocket 1006 kills session drain #48690 covers an xAI WebSocket closing with code 1006.
- openai: gpt-5.6-sol WebSocket inbound queue overflows #49523 covers an OpenAI GPT-5.6 Sol WebSocket inbound queue overflow.
I did not find an existing report for the exact Timed out waiting for WebSocket data error on v2.
Plugins
No OpenCode plugins configured. MCP servers and skills are configured, but the persisted failure is from the OpenAI provider transport.
OpenCode version
OpenCode Desktop v2.0.10
Steps to reproduce
- Open OpenCode Desktop v2.0.10.
- Select the official
openai/gpt-5.6-solmodel with thexhighvariant. - Submit a complex task that produces an extended reasoning response.
- Wait while Desktop displays the thinking state.
- After approximately 310-319 seconds, observe the response being interrupted and automatically retried.
- Inspect the persisted assistant message and observe
provider.transport: Timed out waiting for WebSocket data.
The trigger depends on the model producing a sufficiently long interval without WebSocket data, but it reproduced four times in the session above.
Screenshot and/or share link
No public share link because the session contains private workspace context. Sanitized persisted timings and the exact transport error are included above.
Operating System
CachyOS Linux (rolling), kernel 7.2.6-1-cachyos, x86_64
Terminal
OpenCode Desktop v2
Activity
shssoichiro commentedon Sep 22, 2026
This also affects certain tool calls that await a user response. For example, the Question tool is supposed to await a user response indefinitely. However, if the user does not respond within 5 minutes, the websocket will time out, causing the Question tool to exit in error.
holny commentedon Sep 22, 2026
I'll take this. Looking at packages/core/src/session/model-transport.ts:24,
IDLE_TIMEOUT = "5 minutes"is unconditional — any open stream that goes 5 min without traffic (Question tool awaiting the user, long reasoning chain, slow MCP response) will be reaped.Confirmed shssoichiro's note: the Question tool hit this exact path because it idles while waiting for a user answer.
Plan: thread an "active exchange" signal (or count pending tool calls) into the channel so the idle timer only fires on genuinely idle streams, plus a regression test that holds a Question tool open for >5 min and asserts the socket stays up.
fix(core): raise WebSocket idle timeout and make it configurable