[Bug]: SSH host: each app update leaves the previous relay and its agent PTYs running, and resumes the same sessions under the new relay #26872

Operating system

macOS 26.6.2 (client, Apple Silicon). SSH host: Ubuntu 26.04.1 LTS x86_64, Node v22.23.3.

Orca version

1.4.223 (relay 0.1.0+0d9e2827fa5f). Also seen on 1.4.222 (relay 0.1.0+239293179b77) and two earlier 1.4.22x builds.

Details

Short summary

Every app update installs a new relay version on the SSH host and starts a new relay.js --detached process. The open agent tabs are resumed under the new relay (claude --resume <id>). The previous relay is never stopped, and neither are its PTYs. The agent processes in those PTYs keep running, with no window attached to them.

Result on the host after a few updates: one relay per installed app version, and the same agent session running two or three times at once.

What I observed

Four relay builds were installed over five days. All four relay.js --detached --grace-time 0 processes were still running, one per ~/.orca-remote/relay-0.1.0+<hash>/ directory.

Updating 1.4.222 → 1.4.223 today, with six Claude tabs open on the host:

• a new relay started (0.1.0+0d9e2827fa5f);
• five of the six sessions were started again under it with claude --resume <id>;
• the five original processes stayed alive under the 1.4.222 relay;
• one session id was then running three times (relays from 1.4.22x, 1.4.222 and 1.4.223).

The old relays are still contacted. On every reconnect the app attaches to each old relay for about three seconds and leaves again. Trimmed lines from the relay.log files of the current relay and one old relay:

2026-10-09T10:55:39Z  (new relay) Socket client accepted (clients=1, accepted=7)
2026-10-09T10:55:43Z  (old relay) Socket client closed (clients=0)
2026-10-09T10:55:43Z  (old relay) Grace started (socket client closed): timeoutMs=0, branch=configured, ptys=9, clients=0
2026-10-09T11:27:43Z  (old relay) Socket client closed (clients=0)
2026-10-09T11:27:43Z  (old relay) Grace started (socket client closed): timeoutMs=0, branch=configured, ptys=9, clients=0

So the app knows these relays exist and that they hold PTYs (ptys=9), but it neither adopts those PTYs nor ends them. With --grace-time 0 and ptys > 0 the old relay never exits on its own.

Impact

• Memory. Before cleanup, 14 agent processes sat under two superseded relays and held about 4.1 GB (RSS plus swap). Each one also kept its MCP server children (140–250 MB per session here). The 16 GB host had its 4 GB swap 100% full.
• Correctness. Two or three live processes share one session id and one transcript file. Any of them that has a scheduled or background task keeps acting, unseen. I did not catch a double action, but nothing prevents one.
• It is silent. Nothing in the app shows that old relays or their sessions exist.

Steps to reproduce

1. Add an SSH host. Open a few Claude tabs on it.
2. Update Orca to a version that ships a new relay build, and reconnect.
3. On the host run ps -eo pid,etimes,args | grep -E 'relay.js --detached|claude'.
4. Two relays are running. The sessions from step 1 appear twice: once under the old relay, once under the new one with --resume.

Expected

One of these, when a newer relay takes over a host:

• adopt the old relay's PTYs instead of resuming the sessions in new ones; or
• end the old relay's PTYs once their sessions have been resumed elsewhere, then let the old relay exit; or
• at least show the leftover relays and sessions in the app and offer to stop them.

Workaround

A timer on the host that ends (a) any agent process whose session id also runs under the newest relay, and (b) any relay whose successor has been up for six hours and which has no connected client, together with its PTYs. Transcripts stay on disk, so the sessions can still be resumed.