Repository navigation
[BUG] Desktop: conversation freezes mid-"thinking", no error, must abort and resend — missing watchdog/retry UX #41365
Description
Description
On the Windows desktop app, quite often — especially with models that do long/reasoning "thinking" (e.g. OpenAI/DeepSeek-style reasoning dumps) — the conversation freezes mid-thinking: the agent is stuck in "thinking" state, spinner/tool call never resolves, and no output arrives.
The only workaround is to abort/terminate the conversation and resend the message (losing the reasoning context), which is disruptive for long debugging tasks.
Details of the bug
- User sends a prompt (sometimes after long thinking, sometimes right at start).
- Client shows "thinking…" (or the thinking block dumps) indefinitely; the stream silently stops; no error toast.
- UI (desktop) is stuck; user must hit the abort/stop button and resent the exact same prompt; then it usually works — pointing to a transient stream/connection race, not the model being slow.
Associated issues (other symptoms, same "thinking stuck" family)
- Desktop stuck in "thinking" mode - sidecar stream never completes (v1.17.18, Windows) #36370 (Desktop stuck in "thinking" - sidecar stream never completes, Windows)
- Plan/Build mode sometimes hangs after long reasoning and never emits the final response #37609 (Plan/Build mode sometimes hangs after long reasoning, never emits final response)
- API 404 error silently hangs session in 'thinking' state with no error recovery #38951 (API 404 silently hangs in thinking state, no error recovery)
- bug: UI stuck on 'thinking' indefinitely after stream error, no error displayed or state recovery #32366 (UI stuck on thinking indefinitely after stream error, no error displayed)
- Silent failure: opencode provider returns 500 errors but client drops response without showing error #38644 (provider 500 drops response without showing error)
- Desktop app: "Auto-approve requests" setting toggle cannot be turned on and does not persist #41069 (previously closed as duplicate of Desktop v1.18.3 — "Auto-accept permissions" settings toggle permanently disabled (cursor: not-allowed) #37617 — free-tier model network blips treated as normal; user on this session reported similar)
Suggested improvements
- Watchdog / timeout on the thinking phase: if no chunks received for N seconds (e.g. 60s), surface an explicit error/info banner ("model hasn't responded; retry?") and offer "retry with cached thinking".
- Recover stuck turn automatically: detect stuck state and prompt user "Retry / discard and re-ask" instead of silently dangling.
- Show provider error in the UI (many of these are provider 5xx/empty chunk cases): single toast for "provider error, auto-retried".
- Non-lossy retry: when user aborts+resends, keep the previous reasoning/tool output as context so the retry isn't blind.
This is a frequent occurrence (dozens of similar reports) and the UX cost is high for long sessions.
Activity
github-actions commentedon Aug 9, 2026
This issue might be a duplicate of existing issues. Please check:
If your issue is specifically about the missing watchdog/timeout UX and retry mechanism (rather than just the stuck-thinking symptom), it may be worth keeping open as a feature/UX request. Otherwise, please consider commenting on one of the above.
liudongyan13701205717-source commentedon Aug 9, 2026
The auto-bot listed #36370 / #32366 / #38644 as possible duplicates — those cover the symptom (stuck "thinking", silent stream drop, provider errors not surfaced). This issue's distinct value is the UX/proposal side: a watchdog + timeout + explicit retry-with-cached-thinking UX, i.e. (1) detect a stalled turn, (2) offer "retry / discard and re-ask" instead of silent hanging, (3) keep reasoning context on retry. That's a feature request that complements the bug reports, not a duplicate. If maintainers prefer, I can reduce this to just the watchdog/retry spec and let the bug reports own the diagnosis.
mcj777 commentedon Aug 14, 2026
Freeze at ~14% context fill — same "thinking stuck" family, with log evidence
Environment: Windows 11, OpenCode v1.18.18 desktop (local sidecar server), DeepSeek V4 Pro via API, 1M context window,
reasoningEffort: max.Symptom: when a session reaches ~14% context fill (~140K input tokens), the chat and permission dialogs freeze (red server indicator). No error in UI, nothing in the log — the stream to
deepseek-v4-progoes completely silent (20 min in my last capture), followed byAbortedafter a manual Esc. No crash, no dumps. It self-recovers after 5–30 min, or after Esc → resend.What makes this case notable: it reproduces across different sessions at the same context fill percentage (~14%), suggesting the stall correlates with accumulated context size, not just long reasoning. Same family as #37609 / #36370 / #38951, but with a measurable trigger threshold.
Workarounds confirmed: Esc → resend succeeds; starting a new session before ~100K tokens prevents the freeze.
liudongyan13701205717-source commentedon Aug 14, 2026
@mcj777 thanks for the detailed repro — the ~14% context-fill threshold is a great new data point.
This is the same "stuck thinking / silent stream drop" family as #36370, #32366, #38644, #37609, #38951 — but your capture adds something the others lack: a reproducible trigger threshold (~14% / ~140K input tokens on a 1M window), which points at accumulated-context-size handling rather than just long-reasoning or a one-off provider error.
Where this issue stays distinct (and worth keeping open alongside those bug reports): the UX gap — there's no watchdog, no stall timeout, and no explicit "retry / discard-and-re-ask" affordance when a turn silently hangs. Today the only recovery is a manual
Esc → resendthat throws away reasoning context. A minimal, high-value fix would be:The diagnosis belongs to the bug issues; the watchdog/retry UX is the feature request here. Boosting visibility for both.
liudongyan13701205717-source commentedon Aug 27, 2026
I can reproduce the mid-"thinking" freeze on my end as well. Happy to provide local repro logs / context size at freeze time if it helps narrow down the ~14% context trigger mcj777 identified.
liudongyan13701205717-source commentedon Aug 30, 2026
跟进：目前已有两名真实用户复现——mcj777（~14% 上下文填充 ~140K token 阈值触发冻结，跨会话可复现）和我方（Windows Desktop）。症状归属 #36370/#32366/#37609/#38951 等 bug 报告，本 issue 的价值在于非诊断侧：watchdog + 停顿检测 + 显式"重试/丢弃重问"UX，且保留推理上下文重试。
诉求小结（也可作为最小可评审规格）：
维护者若有排期或需补充规格细节，请指示。愿意提供本地复现日志/冻结时的上下文大小。
opencodejr commentedon Oct 28, 2026
Thanks for the report! To look into this we need a few concrete details. Please describe, briefly and in your own words:
opencode --version). This tells us whether you're on v1 (0.x/1.x) or v2 (2.x).deepseek/deepseek-reasoner), and whether it also happens with other models.%USERPROFILE%\.local\share\opencode\log).You can reply here with the details, or edit the issue. If you edit it, please also leave a comment saying you've updated it so we know you're done.
These existing issues look closely related, ordered from most to least likely. Please check whether one of them already covers your problem:
(#41069 and #37617 seem to be about the auto-approve permissions toggle rather than this hang.)
opencodejr commentedon Oct 31, 2026
We're closing this as not planned because we didn't hear back with the details we asked for: the OpenCode Desktop version (v1 or v2), the exact provider and model, a prompt or steps that cause the freeze, and logs or a screenshot. Without those we can't reproduce the conversation freezing mid-"thinking" or tell which code path is involved.
If it happens again, please open a new issue with those details, or reply here, and link back to this one. Thanks for taking the time to report it!