bug: UI stuck on 'thinking' indefinitely after stream error, no error displayed or state recovery

[Superissac]

Issue

When a stream error occurs (e.g., AI_APICallError, socket closed unexpectedly), the desktop UI gets stuck showing "thinking..." indefinitely. No error message is displayed, no state recovery happens, and the session becomes unusable. The user must restart the app to recover.

Root Cause Analysis

After analyzing multiple server logs from debug dumps:

1. Stream errors are frequent but silently swallowed

   • AI_APICallError: <none> — empty error object, no details from the upstream API
   • AI_APICallError: The socket connection was closed unexpectedly — upstream proxy terminates the SSE stream mid-response
   • These errors are logged on the server side but never propagated to the UI

2. UI state machine never transitions out of 'thinking'

   • After a stream error, the server logs show the session is dead (no further stream events)
   • But the desktop UI continues displaying "thinking..." with no cancel button or error indicator
   • The frontend apparently waits for a stream event that will never come

3. No automatic retry or timeout

   • No retry mechanism after stream failure
   • No client-side timeout to abort stuck states
   • User must manually cancel or restart the app

4. Server log stops processing

   • In one dump, the last log entry at 2026-06-15T01:46:02Z was a cancel event
   • After that, zero log entries despite the UI showing "thinking"
   • This confirms the server stopped processing but the UI never received this state change

Server Log Evidence

# Frequent silent stream errors (no error detail)
level=ERROR message="stream error" providerID=YerPlan modelID=qwen3.6-plus error.error="AI_APICallError: <none>"

# Socket-level failures
level=ERROR message="stream error" error.error="AI_APICallError: Cannot connect to API: The socket connection was closed unexpectedly"

# After stream errors, server stops responding but UI stays 'thinking'
level=INFO message=cancel session.id=ses_13898e204ffemfGewCcp9BrPCN
# ← zero further log entries after this point (01:46 UTC)

Steps to Reproduce

1. Connect opencode desktop to an API provider via an openai-compatible proxy (e.g., https://api.xxx.com/v1)
2. Use a worktree session on a local project directory
3. Send a message that triggers a long-running response
4. Wait for the upstream proxy to drop the connection (intermittent, but happens frequently with unstable proxies)
5. Observe: UI stuck on "thinking...", no error shown, session unresponsive

Expected Behavior

1. Display an error message when the stream fails (e.g., "Connection lost. Retry?")
2. Provide a "Retry" or "Cancel" button
3. Implement a client-side timeout to prevent indefinite stuck states
4. Auto-recover when the server stops responding

Environment

• opencode: 1.17.7 (Desktop app)
• OS: macOS darwin arm64 (M-series)
• Electron: 42.3.3 / Chrome 148
• Provider: openai-compatible proxy (not direct Anthropic/OpenAI)
• Model: qwen3.6-plus (via proxy)
• Node: 24.15.0

Related Issues

• UI stuck on 'Thinking...' when tool output is pending #17655: UI stuck on 'Thinking...' when tool output is pending
• Build mode with Thinking enabled: UI freezes during thinking stream, incomplete output rendering #19512: Build mode with Thinking enabled — UI freezes during thinking stream
• Main & Sub-agents Randomly Freeze Indefinitely: Frontend Permanently Shows "thinking" with No Errors, While Actual LLM Inference Has Already Terminated Prematurely #24342: Main & Sub-agents Randomly Freeze Indefinitely: Frontend Permanently Shows "thinking"
• Critical bug: Opencode desktop get completly stuck #23481: Similar — agents stuck with frontend permanently showing "thinking", no errors

[github-actions]

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

• Web UI shows permanent Thinking spinner after stream interruption or server restart #17680: Web UI shows permanent Thinking spinner after stream interruption or server restart — covers the same frontend symptom (permanent spinner after stream dies)
• Sessions permanently stuck after server restart or stream interruption — no startup recovery for orphaned messages/tool parts #19023: Sessions permanently stuck after server restart or stream interruption — covers the backend root cause (orphaned assistant messages with no time.completed) and proposes the same startup recovery fix

[Superissac]

Updated findings after deep investigation

API works fine (direct curl test)

curl -X POST https://api.qiyue999.com/v1/chat/completions \
  -d '{"model":"qwen3.6-plus","messages":[{"role":"user","content":"Hello"}],"stream":true}'
# Returns valid SSE stream with reasoning_content chunks - works perfectly

But opencode CLI gets stuck even with --pure (no plugins)

opencode --pure /Users/issac/ -m YerPlan/qwen3.6-plus
# Stuck on "thinking..." forever, server logs show stream starts but never completes

Root cause hypothesis

The API returns stream chunks with reasoning_content in the delta:

{"choices":[{"delta":{"content":null,"reasoning_content":"Here's a thinking process..."}}]}

But @ai-sdk/openai-compatible may be expecting reasoning in a different format (e.g., Anthropic-style thinking blocks or OpenAI-style reasoning object). The adapter likely never recognizes the stream as complete when processing reasoning_content from Qwen models, causing the agent loop to hang indefinitely.

This is NOT:

• A plugin issue (--pure same result)
• A desktop UI-only issue (CLI same result)
• An API availability issue (direct curl works)
• A thinking configuration issue (thinking: {type:"disabled"} didn't help)

Likely fix

The @ai-sdk/openai-compatible adapter needs to properly handle reasoning_content in stream chunks from qwen-compatible endpoints. The current implementation may treat it as an incomplete or malformed response type that never transitions to the text phase.

[marceloj]

I'm experiencing the same issue on OpenCode Desktop v1.17.13 on Windows. The UI gets stuck on "thinking..." indefinitely after a stream error, with no error message or recovery. The only way to fix it is to restart the app.

I've reproduced this with 3 different models/providers:

• Mimo v2.5
• DeepSeek (DeepSeek-v4-flash)
• (a third model)

The issue happens with all of them, so it's not model-specific — it's a bug in the desktop app's stream error handling. The session becomes completely unresponsive and there's no cancel/retry option.

Happy to provide debug logs if needed.