OpenCode TUI loses connection with server #3320

Closed
opened 2026-02-16 17:39:38 -05:00 by yindo · 9 comments
Owner

Originally created by @gabrielrinaldi on GitHub (Dec 4, 2025).

Originally assigned to: @rekram1-node on GitHub.

Description

When using OpenCode (I am using Tmux, so don't know if this happens outside Tmux as well) some OpenCode sessions will stop responding and the only way to quit is to kill the pane in Tmux.

I am writing a wrapper for OpenCode so I can start saving debug logs and if I am successful I'll add the logs here as I get a freeze.

At least on my machine this is guaranteed to happen in a session.

Thank you for the amazing tool you created and are constantly improving, it became part of my flow and even though Claude Code is amazing I can't go back.

OpenCode version

1.0.132

Steps to reproduce

  1. Open a Tmux window or more
  2. Open several OpenCode sessions
  3. Use them and switch across them

Screenshot and/or share link

No screenshot available which is ironic since OpenCode becomes a screenshot in itself.

Operating System

NixOS

Terminal

Ghostty

Originally created by @gabrielrinaldi on GitHub (Dec 4, 2025). Originally assigned to: @rekram1-node on GitHub. ### Description When using OpenCode (I am using Tmux, so don't know if this happens outside Tmux as well) some OpenCode sessions will stop responding and the only way to quit is to kill the pane in Tmux. I am writing a wrapper for OpenCode so I can start saving debug logs and if I am successful I'll add the logs here as I get a freeze. At least on my machine this is guaranteed to happen in a session. Thank you for the amazing tool you created and are constantly improving, it became part of my flow and even though Claude Code is amazing I can't go back. ### OpenCode version 1.0.132 ### Steps to reproduce 1. Open a Tmux window or more 2. Open several OpenCode sessions 3. Use them and switch across them ### Screenshot and/or share link No screenshot available which is ironic since OpenCode becomes a screenshot in itself. ### Operating System NixOS ### Terminal Ghostty
yindo added the opentuibug labels 2026-02-16 17:39:38 -05:00
yindo closed this issue 2026-02-16 17:39:38 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Dec 4, 2025):

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

  • #5043: Suspend (ctrl + z) pauses api calls for all opencode instances

The #5043 issue describes API calls stopping when running multiple OpenCode instances and one is suspended. Your issue reports sessions losing connection and becoming unresponsive when switching between multiple Tmux sessions running OpenCode. These sound like related symptoms of the same underlying connection/session management problem.

Feel free to ignore if your specific case is different.

@github-actions[bot] commented on GitHub (Dec 4, 2025): This issue might be a duplicate of existing issues. Please check: - #5043: Suspend (ctrl + z) pauses api calls for all opencode instances The #5043 issue describes API calls stopping when running multiple OpenCode instances and one is suspended. Your issue reports sessions losing connection and becoming unresponsive when switching between multiple Tmux sessions running OpenCode. These sound like related symptoms of the same underlying connection/session management problem. Feel free to ignore if your specific case is different.
Author
Owner

@rekram1-node commented on GitHub (Dec 4, 2025):

lookin into it

@rekram1-node commented on GitHub (Dec 4, 2025): lookin into it
Author
Owner

@aaronnewsome commented on GitHub (Dec 5, 2025):

I'm seeing the same issue, using Tmux, but also just regular ssh sessions. Most frequently I see this when Opencode prompts me to approve something and I don't respond right away. Today I stepped away for a moment to make a coffee, came back and tried to accept the prompt and opencode would not respond. Esc doesn't respond, d key, a key, ctrl+p, nothing would work. The text "spinner" was still darting left to right and back again, but it doesn't respond to key input. The only way forward is to kill opencode

@aaronnewsome commented on GitHub (Dec 5, 2025): I'm seeing the same issue, using Tmux, but also just regular ssh sessions. Most frequently I see this when Opencode prompts me to approve something and I don't respond right away. Today I stepped away for a moment to make a coffee, came back and tried to accept the prompt and opencode would not respond. Esc doesn't respond, d key, a key, ctrl+p, nothing would work. The text "spinner" was still darting left to right and back again, but it doesn't respond to key input. The only way forward is to kill opencode
Author
Owner

@gabrielrinaldi commented on GitHub (Dec 6, 2025):

I found something today, not sure if related, but on nix @parcel/watcher-linux-x64-glibc is not installed. Might be unrelated, but I'll try to see if I can add an overlay to fix it.

@gabrielrinaldi commented on GitHub (Dec 6, 2025): I found something today, not sure if related, but on nix `@parcel/watcher-linux-x64-glibc` is not installed. Might be unrelated, but I'll try to see if I can add an overlay to fix it.
Author
Owner

@gabrielrinaldi commented on GitHub (Dec 6, 2025):

Here are my findings so far:

Log Evidence

  1. SSE connection completes immediately instead of staying open:
INFO service=server method=GET path=/event request
INFO service=server status=started method=GET path=/event request
INFO service=server event connected
INFO service=server status=completed duration=0 method=GET path=/event request

The /event SSE endpoint shows status=completed duration=0 - it connects and immediately closes instead of remaining open as a long-lived stream.

  1. Periodic disconnects every ~5 minutes:
02:24:47 - connected
02:30:43 - disconnected (6 min)
02:35:43 - disconnected (5 min)
02:39:53 - disconnected (4 min)
  1. Unsubscribe before each disconnect:
INFO +268952ms service=bus type=* unsubscribing
INFO +0ms service=server event disconnected

The client unsubscribes from all events (type=*) after ~4-5 minutes of the connection being "open".

Current Behavior

  • SSE stream connects then immediately completes
  • UI freezes, particularly when waiting for user input
  • Backend continues processing but UI shows no updates
  • No way for manual reconnection

Environment

  • NixOS (nixpkgs opencode package)
  • OpenCode version: 1.0.134
  • Runtime: Bun

Additional Notes

  • Also seeing @parcel/watcher-linux-x64-glibc module missing errors (separate issue, non-blocking)
@gabrielrinaldi commented on GitHub (Dec 6, 2025): Here are my findings so far: **Log Evidence** 1. SSE connection completes immediately instead of staying open: ``` INFO service=server method=GET path=/event request INFO service=server status=started method=GET path=/event request INFO service=server event connected INFO service=server status=completed duration=0 method=GET path=/event request ``` The /event SSE endpoint shows status=completed duration=0 - it connects and immediately closes instead of remaining open as a long-lived stream. 2. Periodic disconnects every ~5 minutes: ``` 02:24:47 - connected 02:30:43 - disconnected (6 min) 02:35:43 - disconnected (5 min) 02:39:53 - disconnected (4 min) ``` 3. Unsubscribe before each disconnect: ``` INFO +268952ms service=bus type=* unsubscribing INFO +0ms service=server event disconnected ``` The client unsubscribes from all events (type=*) after ~4-5 minutes of the connection being "open". **Current Behavior** - SSE stream connects then immediately completes - UI freezes, particularly when waiting for user input - Backend continues processing but UI shows no updates - No way for manual reconnection **Environment** - NixOS (nixpkgs opencode package) - OpenCode version: 1.0.134 - Runtime: Bun **Additional Notes** - Also seeing @parcel/watcher-linux-x64-glibc module missing errors (separate issue, non-blocking)
Author
Owner

@wildwasser commented on GitHub (Dec 9, 2025):

I'm having the same (or at least as far as I can tell VERY similar) issues... and I'm using VSCode (version details below) on a macstudio m4 max. When it crashes out, VSCode loses connection to ALL active terminals, not just the one(s) with opencode running in them. At the moment I only have 1 opencode instance running at a time, and I haven't been and did not suspend the session or anything weird like that, I did have issues with switching between delegated subagent tasks, but this wasn't the trigger for the crash... I'm not sure if it only crashed when the primary agent had delegated a task to a subagent.

Notably after a terminal restart there is a stream of numbers like 35;78;89M35;78;89M33;74;89M35;75;89M35;78;87M flowing into the terminal.

Actually, when watching this now for a few minutes, it does seem to be an issue when a subagent completes a task, and there's a confirmation/completion prompt coming back to the primary agent, basically it's taking longer to process that return input, and if i leave it alone it catches up eventually... nothing moves, no response to any keystrokes, it's just peaking out trying to process the info coming back in... well, that's what I see. Maybe there's something else also.

Software details, if that helps:
both OpenCode 1.0.134 AND OpenCode 1.0.138

VS Code Version: 1.106.3 (Universal)
Commit: bf9252a2fb45be6893dd8870c0bf37e2e1766d61
Date: 2025-11-25T22:28:18.024Z
Electron: 37.7.0
ElectronBuildId: 12781156
Chromium: 138.0.7204.251
Node.js: 22.20.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 24.6.0

@wildwasser commented on GitHub (Dec 9, 2025): I'm having the same (or at least as far as I can tell VERY similar) issues... and I'm using VSCode (version details below) on a macstudio m4 max. When it crashes out, VSCode loses connection to ALL active terminals, not just the one(s) with opencode running in them. At the moment I only have 1 opencode instance running at a time, and I haven't been and did not suspend the session or anything weird like that, I did have issues with switching between delegated subagent tasks, but this wasn't the trigger for the crash... I'm not sure if it only crashed when the primary agent had delegated a task to a subagent. Notably after a terminal restart there is a stream of numbers like 35;78;89M35;78;89M33;74;89M35;75;89M35;78;87M flowing into the terminal. Actually, when watching this now for a few minutes, it does seem to be an issue when a subagent completes a task, and there's a confirmation/completion prompt coming back to the primary agent, basically it's taking longer to process that return input, and if i leave it alone it catches up eventually... nothing moves, no response to any keystrokes, it's just peaking out trying to process the info coming back in... well, that's what I see. Maybe there's something else also. Software details, if that helps: both OpenCode 1.0.134 AND OpenCode 1.0.138 VS Code Version: 1.106.3 (Universal) Commit: bf9252a2fb45be6893dd8870c0bf37e2e1766d61 Date: 2025-11-25T22:28:18.024Z Electron: 37.7.0 ElectronBuildId: 12781156 Chromium: 138.0.7204.251 Node.js: 22.20.0 V8: 13.8.258.32-electron.0 OS: Darwin arm64 24.6.0
Author
Owner

@gabrielrinaldi commented on GitHub (Dec 20, 2025):

Just to note here that up to 1.170 that I've tested things seems to be a lot better for me. Not sure if this was fixed, haven't tested newer versions yet

@gabrielrinaldi commented on GitHub (Dec 20, 2025): Just to note here that up to 1.170 that I've tested things seems to be a lot better for me. Not sure if this was fixed, haven't tested newer versions yet
Author
Owner

@rekram1-node commented on GitHub (Dec 20, 2025):

I believe dax shipped some heartbeat fixes so this should be fixed? We noticed it on desktop app so i think he found root issue

Gonna close for now… if it happens more then ill reopen

@rekram1-node commented on GitHub (Dec 20, 2025): I believe dax shipped some heartbeat fixes so this should be fixed? We noticed it on desktop app so i think he found root issue Gonna close for now… if it happens more then ill reopen
Author
Owner

@wildwasser commented on GitHub (Dec 22, 2025):

I still had the issue after the last wave of updates, I'm starting to think that it's something to do with the amount of memory being used for all of the subagent sessions in the background, or maybe when I load in a session after an update. If I start with fresh sessions after an update I don't have the issue.

Considering how many updates there are coming through on this repo, it's going to happen more often. My work around at the moment is to leave opencode running until I'm finished with that session, dropping everything every now and then to restart and upgrade with a fresh session.

I think the issue is still open, if it happens again, I'll try to be more vigilant about versions and situations... what I saw could have caused itt by my actions.

@wildwasser commented on GitHub (Dec 22, 2025): I still had the issue after the last wave of updates, I'm starting to think that it's something to do with the amount of memory being used for all of the subagent sessions in the background, or maybe when I load in a session after an update. If I start with fresh sessions after an update I don't have the issue. Considering how many updates there are coming through on this repo, it's going to happen more often. My work around at the moment is to leave opencode running until I'm finished with that session, dropping everything every now and then to restart and upgrade with a fresh session. I think the issue is still open, if it happens again, I'll try to be more vigilant about versions and situations... what I saw could have caused itt by my actions.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#3320