Repository navigation
[Bug]: Remote terminal tabs resurrect on Desktop and throw 'tab_not_found' when closed via Server CLI #17767
Description
Summary
We are experiencing a combination of the behaviors tracked in #11800 and #10747, which effectively traps remote terminal tabs and prevents them from being closed through normal workflows.
When attempting to close remote terminal tabs from Orca Desktop (Windows 10) connected to an orca-ide serve headless Linux runtime:
- The Windows client visually closes them, but they reappear upon reconnecting because the server never receives/processes the close intent (similar to Paired viewer retains unclosable null-PTY terminal ghosts after host topology advances #11800 / Remote env: "explicitly killed" ghost terminal tabs accumulate after host runtime restart (not prunable) #9585).
- Attempting to manually clean up the zombie tabs directly on the Linux server using a loop of
orca terminal close --terminal <handle>fails withtab_not_found(exactly as described in CLIterminal closecan never close a background tab that failed reveal — headless close path throwstab_not_foundfor tabs that were never persisted #10747), despiteorca terminal listshowing them as connected and alive.
Environment
- Server: Ubuntu running
orca-ide serve(tested on both v1.4.182 and v1.4.193) over Tailscale. - Client: Orca Desktop on Windows 10.
- Impact: Dozens of orphaned PTYs remained alive in
orca terminal list --jsonon the server under the Windows client'sexecutionHostId.
Workaround Used
The only way to forcefully clear the zombie tabs was to run orca terminal stop --worktree <path> directly on the remote Linux shell, or completely restart the orca-server.service daemon to kill the underlying PTY processes.
Adding this report to group the impact of the UI routing bug and the CLI headless close path bug, as together they leave users with no UI-driven or standard CLI way to clean up remote environments.
Activity
LesleyMurfin commentedon Sep 17, 2026
Cross-referencing: PR #21277 touches the client-side close intent and error recovery handling for remote/desktop tabs. In #21277, client-side close intents remain durable and anchored when absent-target errors (like
tab_not_foundorselector_not_found) are returned during close, preventing infinite resurrection flicker loops. Note that the underlying server CLI routing issue described here remains open for the headless/server side.OrcaWin commentedon Oct 10, 2026
Status: two of the three causes are fixed on main. #27119 makes the server commit a close in the saved partition that actually holds the tab, so
orca terminal closeno longer answerstab_not_foundfor a spill-partition tab. #27132 makes the client's × always close, even before the worktree catalog loads. Still open: a close sent to a paired server is lost when the connection drops mid-close (the durable client outbox is the next step).