[Bug] Coding Server Terminal Geting Stuck #15803

Activity

1. orca-discord-issues

   added

   bugSomething isn't workingSomething isn't working

   on Aug 21, 2026
2. AmethystLiang

   assigned

   nwparker

   on Aug 21, 2026
3. yzxcj797 commented on Aug 21, 2026

   

   yzxcj797

   on Aug 21, 2026

   Contributor

   More actions

   Thanks for the report — to make this actionable a few details would pin which layer is sticking:

   1. Where does it stick — the terminal pane freezes (no new output but the process keeps running on the server), or the whole client connection to the coding server stalls (all panes, sidebar status dots, etc.)?
   2. What the server sees — on the hub machine, does orca terminal list --json still report the stuck session connected: true? And is the underlying agent process alive (ps / Activity Monitor)?
   3. When — does it correlate with the Mac sleeping/waking, a network change (Wi-Fi ↔ VPN ↔ Tailscale), or long idle periods with no output?
   4. Orca version on hub + clients, and whether the hub is orca serve/remote runtime or desktop.

   One known relevant fix already landed recently: long silent operations on the runtime's unix-socket transport (e.g. a forced worktree rm) could idle-reap the connection at 30s and surface as runtime_unavailable afterwards (#15663, fixed by #15730). If your stalls end in disconnect errors, that may be the same family — the details above would tell.
4. orca-discord-issues commented on Aug 21, 2026

   

   orca-discord-issuesBot

   on Aug 21, 2026

   Author

   More actions

   Dave Fano via Discord

   Thanks — I’m seeing two distinct failure modes:

   Most commonly, only the terminal pane freezes. The sidebar/client remain responsive, the underlying process stays alive, and orca terminal list --json still reports the session connected: true and writable: true. Output continues on the host, but the pane stops repainting. A hard refresh immediately restores it. This often happens after switching away from the terminal and back. Logs around the freeze show repeated webgl-atlas-reset events.

   Less often, the remote-runtime connection itself stalls after the client has been backgrounded. The SSH worker relay may remain connected while the client↔hub WebSocket reconnects.

   Topology:
   Apple-silicon MacBook Pro with M5 Max: macOS desktop Orca acting as the coding-server hub
   Apple-silicon MacBook Air with M5: macOS desktop thin client
   Additional Apple-silicon Macs connected as SSH worker hosts
   Tailscale between machines

   I reproduced the renderer freeze on official Orca 1.4.185. I’ve also tested with a 1.4.186-based build. During captures, neither Mac slept, Tailscale remained direct at roughly 11 ms with 0% loss, sockets stayed established, and the underlying agent/shell process remained alive.

   I’ve also encountered a separate case where Orca continued reporting connected/writable, but an actual relay write failed with EIO; the shell process was still alive, but the relay’s PTY handle was stale.

   The #15663/#15730 Unix-socket idle-reap issue doesn’t appear to explain the renderer-only freezes because the connection and process remain healthy and refresh only rebuilds the UI. It could be adjacent to the full remote-runtime stalls, though.

   I can provide timestamped logs and exact terminal-list output from the next occurrence. Which log bundle/files would be most useful?
5. orca-discord-issues commented on Aug 22, 2026

   

   orca-discord-issuesBot

   on Aug 22, 2026

   Author

   More actions

   nwparker via Discord

   thanks will try to take a deeper look Dave Fano 🫡
6. orca-discord-issues commented on Aug 23, 2026

   

   orca-discord-issuesBot

   on Aug 23, 2026

   Author

   More actions

   Dave Fano via Discord

   So I've been using SSH and I just started to have all my machines only use the coding server. And it's very early, but it's working significantly better. So this may have been me not doing it the right way.
7. Naroh091 commented on Aug 27, 2026

   

   Naroh091

   on Aug 27, 2026

   Last edited by Naroh091

   More actions

   I'm having the same behaviour in a quite similar topology.

   Remote coder workspaces to which a Orca server (WSL, Version 1.4.190) connects through SSH. That Orca server is the hub to other Orca clients through Tailscale (same version on Mac, and the Android app).

   Most commonly the panels freeze - if I log in into the Orca server environment through VNC I can see the server shows new content in those terminals. Restarting the client usually helps.

   In other less common cases, the server is just unable to connect to the remote agents so I have to close them (Ctrl+C works in Orca) and reopen them again and resume the session.
8. nwparker commented on Aug 27, 2026

   

   nwparker

   on Aug 27, 2026

   Contributor

   More actions

   Thanks for the reports. I'm working on some changes now and later consolidating SSH/remote stuff down to decrease surface area + isolated fixes

   👍React with 👍1Reacted by David Fernández
9. OrcaWin

   added the

   Bug

   issue type on Sep 19, 2026
10. orca-discord-issues

    closed this as completedon Sep 22, 2026
11. nwparker

    reopened this on Oct 7, 2026
12. nwparker commented on Oct 18, 2026

    

    nwparker

    on Oct 18, 2026

    Contributor

    More actions

    Thanks Dave and @Naroh091 for the detailed reports. We've shipped a series of fixes for each of the failure modes you described, and all of them are in v1.4.229:

    • Panes that stop drawing after you switch away and back, while the program keeps running: fix(terminal): bound WebGL context-loss retries on tab reveal #16338, perf(renderer): collapse duplicate reveal atlas rebuilds #17762, fix(terminal): a reveal after hidden output was dropped always restores it #29342, fix(terminal): a cold-parked terminal reveal paints once, at the pane's own size #29331, fix(remote-terminal): revealing a remote pane no longer triggers a second clear-and-repaint #29285, fix(remote-terminal): draw the host's saved screen when a reattached pane's first image is blank #29261, fix(remote-terminal): keep live output flowing during resync and retry an unanswered one #29236, fix(remote-terminal): reattach a healthy remote pane promptly after a worktree switch #29210
    • The connection to the coding server stalling after the client sleeps or loses the network: fix(ssh): retry a stalled SSH reconnect when the machine wakes or the network returns #29237, fix(ssh): no probe stall on the first remote action after a pause #29240, fix(terminal): replay a viewport claim made during remote recovery before typing #29892
    • A terminal that says it's connected but can't actually be written to (the EIO case): fix(pty): invalidate the descriptor when node-pty gives up the handle #17930, fix(terminal): tell panes their daemon died at once and say when typed input was lost #29660. A pane now tells you right away when its terminal service has died, and whether typed input was lost.
    • The server losing contact with remote agents until you restart them: fix: avoid credit deadlock during large SSH PTY recovery #19026, fix(daemon): pause producers when stream backlogs grow #20947, fix(runtime): stop a remote-typed terminal hidden on the host from reconnecting on every send #29252

    I'm closing this as fixed. If a pane freezes again on v1.4.229 or later, please open a new issue and include:

    • the Orca version on the hub and on each client;
    • how the machines connect (SSH, WSL, Tailscale);
    • whether a refresh brings the pane back;
    • the output of orca terminal list --json, captured during the freeze.
13. nwparker

    closed this as completedon Oct 18, 2026