opencode serve crashes every hour or two with ERR_STREAM_DESTROYED #57638

Activity

1. opencode-agent commented on Oct 21, 2026

   

   opencode-agentBot

   on Oct 21, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report and the stack trace. I couldn't reproduce the crash on 1.18.35, but the trace gives a lead.

   What I tried (opencode serve on Linux):

   • Kept many SSE clients (/event, /global/event, /api/event) connecting and then dropping abruptly for several minutes, with TCP resets, half-read streams and clients that stop reading, while events kept flowing. The server stayed up.
   • Connected a fake language server, made it crash or close its stdin after opening a file, then kept reading, writing and editing files. The server still stayed up.

   What the trace suggests: in the 1.18.35 build, the doWrite → write → new Promise frames match the JSON-RPC writer OpenCode uses to talk to LSP servers over their stdin. So the failing write is most likely to a language server that has already exited or closed its pipe, not to your SSH/SSE client. That would also fit why it happens at random.

   These would help narrow it down:

   • Which languages and LSP servers are active in that project (the output of curl http://127.0.0.1:<port>/lsp while the server is running would show them), and any lsp settings in your opencode.json.
   • The OpenCode log around a crash time, from ~/.local/share/opencode/log/, and the journalctl --user -u opencode.service lines just before the stack trace. Look especially for LSP servers exiting or restarting.
   • Whether the crashes stop if you disable LSP for a while ("lsp": false in opencode.json).

   Also, 1.x is the old v1 line, which only gets critical fixes. If you can, check whether v2 (@opencode/cli, the opencode serve command) behaves the same for you.

   Related, though not the same error: #41968 (v2 service crashing on unhandled EPIPE from broken pipes), plus #26667 and #28597 (unhandled abort errors crashing the server).
2. lazyskulptor commented on Oct 21, 2026

   

   lazyskulptor

   on Oct 21, 2026

   Author

   More actions

   Thanks for the detailed pointers.

   • curl /lsp while it's running shows just the one active server for the open project (terraform), but the log shows all 37 configured servers get enabled on every run ("enabled LSP servers" serverIds="zls, yaml-ls, ... pyright ..."). opencode.json just has "lsp": true, nothing custom.
   • I grepped ~/.local/share/opencode/log/opencode.log around both crash timestamps. Both times, the line right before the crash is a burst of formatting file=... / "touching file" across many files of different languages (Python, YAML, JSON, Jinja2 templates) within ~150ms, then the crash. No explicit LSP spawn/exit/crash log line appears near either crash, so I don't have direct proof it's an LSP pipe, just the timing correlation.
   • I tried disabling LSP ("lsp": false) and reproducing with a throwaway session editing 5 files (py/yaml/json/j2/yml) — no crash. But I don't think this actually tested your hypothesis: my edits went through the agent's normal one-tool-call-per-file loop (seconds apart), while the real crash's 15 files were all touched back-to-back in ~150ms with no visible per-file permission step, which looks like a different, internal bulk pass (maybe a formatting/snapshot sweep), not individual agent tool calls. I wasn't able to trigger that exact code path from the outside, so this test is inconclusive rather than a clean refutation/confirmation.

   Happy to grab anything else if there's a more specific way to trigger that bulk formatting pass, or if there's a debug flag that would log which file/LSP server the write was destined for.