Repository navigation
TUI: open session closes / goes home when its re-fetch after a reconnect fails #61243
Description
Description
With several TUIs attached to the shared background service, open sessions sometimes close (or the tab falls back to the home screen) by themselves. I then have to find the session again.
On every reconnect, the session route re-fetches the open session. Any failure in that fetch is treated as "session gone":
packages/tui/src/routes/session/index.tsx:337-367 (v2.2.5, unchanged on dev)
- If
data.session.get(id)is empty after the sync, it showsSession not found: <id>and callssessionTabs.close(sessionID)/navigate({ type: "home" }). - If the sync rejects for any reason, it shows the error and does the same thing. That includes timeouts and
ECONNREFUSEDwhile the service is restarting.
There's no retry, and transient errors are handled the same as a confirmed not-found. With many TUIs reconnecting at once to a service that's still starting, some of these fetches fail and those sessions get closed.
Evidence (~/.local/share/opencode/log/opencode.log, v2.2.5, macOS)
2026-11-01T17:47:53Z: about 25 clients logevent stream disconnectedwithECONNRESETwithin 3 ms. A few seconds later there'sECONNREFUSED, thenTimed out connecting to server.17:48:55Zto17:50:56Z:serve --servicestarts 6 times. One instance getsSIGTERM11 s after starting.2026-11-02T07:45:07Z: a new service fails because port 49374 is still held by the previousserve --serviceprocess.
The toast isn't logged, so I can't match a specific closed tab to a timestamp. The timing fits what I see, though.
Possibly related: with N clients, each one can terminate a service it considers unresponsive after 3 probe timeouts (packages/client/src/effect/service.ts:75-87). That may be what turns one slow restart into the restart loop above. See #36285.
Expected
The session stays open across a service restart or reconnect. Close the tab or go home only when the server confirms the session doesn't exist (not-found response or session.deleted). On transient errors, keep the view, retry with backoff, and maybe show a "reconnecting" state.
#57594 made the same change for the "location unavailable" prompt.
Environment
- About 25 TUIs in terminal multiplexer panes, shared service enabled (
service.json"disabled": false)
Plugins
No response
OpenCode version
2.2.5 (Homebrew)
Steps to reproduce
No response
Screenshot
No response
Operating System
macOS
Terminal
No response
Activity
opencodejr commentedon Nov 2, 2026
Thanks for the detailed report and log evidence. The code path you point to is correct: on
dev, the session route re-syncs the open session every time the connection becomesconnected, and any rejection from that sync closes the tab or goes home, transient errors included.I think this is a duplicate of #59542, which reports that a transient failure of that same session read sends a resumed session home and is never retried. The open fix there, #59543, retries transient session reads and gives up only on permanent errors. That should also cover the reconnect case you describe.
Possible duplicates and closely related issues, ordered from most to least likely:
SessionNotFoundErrorafter a service restart. It was closed automatically and never merged.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
RuriRyan commentedon Nov 2, 2026
Duplicate of #59542
opencodejr commentedon Nov 3, 2026
Closing this as a duplicate of #59542, since there hasn't been a reply in the past day. That issue covers the same bug: a transient failure of the open session's read closes the tab or goes home instead of retrying. The proposed fix, #59543, retries transient errors and acts only on permanent ones. Please follow #59542 for updates.
Thanks again for the log analysis. If what you see turns out to be different, for example the session is still closed even when the server confirms it exists, reply here and we can reopen.