OpenCode TUI loses connection with server

[gabrielrinaldi]

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

[github-actions[bot]]

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.

[rekram1-node]

lookin into it

[aaronnewsome]

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

[gabrielrinaldi]

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]

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)

[wildwasser]

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

[gabrielrinaldi]

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

[rekram1-node]

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

[wildwasser]

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.