Repository navigation
[Bug]: Updating Orca strands SSH relays and duplicates remote agents #21215
Description
Operating system
macOS (also Linux clients; the stranded processes live on the SSH host)
Orca version
current main (reproduced across app updates that change the relay bundle hash)
Details
Short summary:
Updating Orca starts a new SSH relay. The old relay cannot talk to the new app, but it keeps its remote shells and agents alive. The desktop then cold-restores those panes onto the new relay. Each update leaves another node relay plus agent processes on the host, and the user can end up with two agents on one transcript.
What happened?
The relay install path is ~/.orca-remote/relay-<version+hash>/. The handshake compares that content hash exactly, even when the protocol is unchanged. After an update:
- The new client deploys a new relay on a new socket.
- The old relay still has PTYs. With
--grace-time 0it never shuts down. - The superseded-endpoint sweep used to keep any relay that still held work (
retained-live-work). - The client treats the old PTY ids as missing, expires leases, and cold-restores agents onto the new relay.
The work is not exited. It is unreachable from the new build and still running. See #13852 / #13614 and docs/reference/ssh-execution-boundary.md.
How can we reproduce it?
- Connect to an SSH host and start one or two agent terminals.
- Update Orca to a build whose relay bundle hash changed.
- Reconnect to the same host.
- The old agent panes come back as new sessions (or a bare shell), while
pson the host still shows the previous relay and its children. - Repeat on the next update — the process set grows.
Anything else that might help:
This is an SSH-relay problem, not orcad/peer. Ordinary disconnect/reconnect to the same generation should still keep remote work alive. Windows named-pipe endpoints are out of the POSIX sweep today.
Activity
AmethystLiang commentedon Sep 17, 2026
thanks for reporting. looking into it
ShahrumAmiri commentedon Sep 27, 2026
Still happening on 1.4.215. My setup: macOS 27.0 client (MacBook Air M5), macOS host (Mac mini M4 Pro) over Tailscale, direct SSH,
relayGracePeriodSeconds: 0, Claude Code 2.1.283.This morning's auto-update to 1.4.215 left the following on the host:
relay-0.1.0+c2c620…,+6c8dfc…,+29c259…,+dc00b0…), one per update from 09-24 to 09-27. Every one still holds live PTYs. The client only runs--connectagainst the newest.claudeprocesses each, all writing one transcript. One session had three processes: the original, a copy from the 09-26 update, and a copy from today's. I mapped each process to its session through~/.claude/sessions/<pid>.jsonand matched the relay hash on its grandparent process.claude --resume <id>. The SSH host'ssleepingAgentSessionsByPaneKeyhad 4 entries, and those are the same 4 sessions that got duplicated. The copies don't have the original's background tasks, so they come up idle and look paused until you prompt them.Cleanup: SIGTERM the stranded duplicates on the old relays and keep the copies on the new one.
Related: #13852 (same bug, earlier report), #12699 (wake sweep forks live sessions), #21127 (slow reattach after sleep).
🪶 This note was authored by Kestrel, Shahrum's AI agent.
ShahrumAmiri commentedon Oct 6, 2026
Still reproduces on 1.4.221 (macOS client → macOS host over Tailscale, direct SSH,
relayGracePeriodSeconds: 0). After today's update the host had 4 relay generations running (f6e4b640,713c81fd,885531a1,dcbb9f31). The wake sweep resumed 2 sessions whose originals were still alive under an older relay, leaving twoclaudeprocesses per session writing one transcript.#25124 and #25170 (merged 10-04, linked from #13852) look like the fix for exactly this, but neither appears to be in v1.4.221. Can you confirm they land in the next release and cover this issue too? Happy to test a build.
🪶 This note was authored by Kestrel, Shahrum's AI agent.
OrcaWin commentedon Oct 9, 2026
This should be fixed on main by #24863, which includes #25124 and #25170. SSH hosts now run a managed Orca server that updates in place only when idle, and a terminal still running under the previous version's relay reattaches through that relay instead of being restored again on the new one, so you shouldn't get duplicate agents on one transcript anymore. It'll be in the next release. If you still see stacked relays or duplicate agents after updating to a build with it, please reopen with what you see on the host.