Repository navigation
opencode reload interrupts in-flight turns and leaves them permanently stuck in running — session unusable until a full restart #59726
Description
Description
Running opencode reload while a turn is streaming kills the stream and leaves that turn stuck in running with no self-healing observed over a 10-minute window:
- the interrupted assistant message stays partial (no completion timestamp) and the session keeps reporting as active
- subsequent prompts to the session are accepted (HTTP 200) but stay unprocessed
- the daemon log only shows the normal
location services reloaded count=1line — no errors beyond the known-unrelated NixOS: native recursive FS watcher never loads (libstdc++.so.6 not found) #53210 watcher noise
Per our source read at the pinned version below, the boot-time resumeSuspendedSessions recovery that absorbs daemon crashes does not cover reload: no restart-notification is injected and nothing resumes the orphaned turn. Only a full service restart recovers the session (and the restart-resume path then completes the work correctly).
The net effect is that kill -9 on the daemon is easier to recover from than reload, which is presumably meant as the safer, cheaper alternative.
Related reload pathologies, different symptoms: #57719 (Windows crash in ServerProcess.start), #54827 (503 + stale location) — on Linux we instead see in-flight sessions silently stuck.
Plugins
(none required — reproduces with a stock session)
OpenCode version
2.0.26 (commit 0d61729b3f), packaged via Nix
Steps to reproduce
Isolated environment (fresh $XDG_* dirs — the client commands below run with the same $XDG_* so they target the isolated daemon), an OpenAI-compatible mock provider streaming slowly (500ms/chunk) so the reload lands mid-stream:
- Start
opencode serve --servicein the isolated env; open a session; submit a prompt that produces a long streaming completion. - While the assistant is streaming, run
opencode reload(confirmed in the daemon log:location services reloaded count=1). - The stream stops and the turn never terminates: the session stays active/
running(visible via/api/session). - Submit another prompt to the same session — accepted, still unprocessed 10 minutes later.
opencode service restart— boot recovery injects the restart notification and the session resumes and completes.
Expected Behavior
Either reload waits for in-flight turns to finish before rebuilding location services, or interrupted turns get the same resume treatment as a daemon crash (claim-based recovery). Silently stranding the session should not be possible.
Actual Behavior
The in-flight turn is killed mid-stream and stuck in running; the session no longer processes input; only a full restart recovers.
Screenshot
n/a
Operating System
NixOS 26.11 (x86_64)
Terminal
Alacritty
Activity
opencodejr commentedon Oct 27, 2026
Thanks for the detailed report. I couldn't reproduce this on 2.0.26 so far.
What I tried:
@opencode/[email protected](installed with bun, not Nix) on Linux, with isolatedXDG_*dirs andopencode serve --service. The provider was an@ai-sdk/openai-compatiblemock streaming 20 chunks 500ms apart. In each caseopencode reloadran mid-stream, and the daemon loggedlocation services reloaded count=1:opencode run --format json, reload after 4s: the stream was never cancelled. The assistant message completed (finish: stop), the session went toidle/outcome: succeeded, and a follow-up prompt to the same session was processed normally.shellwithsleep 8): the tool and the next model step both completed.POST /api/session/{id}/promptwith no client attached, then two reloads: it completed.What would help:
opencode run, or a direct API call (which endpoint and body). Also, which clients are attached while you reload?/api/session/{id}/messageoutput for the stuck session, plus the full daemon log around the reload (from$XDG_DATA_HOME/opencode/log/), ideally with--log-level debug.bun add -g @opencode/[email protected]) or a newer release, to rule out anything specific to the Nix package.Related issues, most likely first:
running/api/eventstreams mid-turnopencodejr commentedon Oct 30, 2026
We're closing this for now because we haven't heard back. On 2.0.26 we ran
opencode reloadmid-stream in several ways: during a plainopencode run, at different points in the turn, with ashelltool call running, and with a prompt sent viaPOST /api/session/{id}/promptand no client attached. Every turn completed and the session never stayed stuck inrunning. So we still need what makes your setup different: how the prompt is sent and which clients are attached, the/api/session/{id}/messageoutput and the daemon log around the reload, your mock provider and provider config, and whether the npm build (@opencode/cli) behaves the same as the Nix one. If you can share those, or it still happens on a newer release, please reply here or open a new issue that links to this one. Related: #52846, #54282.