[Bug]: `orca environment rm` does not stop the connection — the running app keeps reconnecting to the removed environment until restart

Operating system

macOS

Orca version

1.4.204 (both machines)

Details

Short summary

Correction (see comment): the GUI trash button is not affected — runtimeEnvironments:remove does tear the transport down. This is orca environment rm only, because the CLI is a separate process that rewrites the store file and never reaches the running app. Root cause and a suggested fix are in that comment.

orca environment rm — and the trash button in Settings → Remote Orca Servers — orca environment rm removes the environment from orca-environments.json, but the running client keeps the live WebSocket to that endpoint and re-establishes it when the connection drops. The removal only takes effect after the client app restarts. Meanwhile orca environment list reads the persisted file, so the removed server is invisible while it is still connected; the only way to see the discrepancy is lsof/netstat on port 6768.

What happened

Two machines, A and B, each running Orca as both client and server. A had two saved environments pointing at B's runtime over two different network paths (a Tailscale address and a WireGuard overlay address). I removed the overlay one on A.

1. T+0 — orca environment rm --environment <name> returned ok: true with the removed record. orca environment list on A then showed only the Tailscale environment.
2. T+6min — A still had an established outbound connection to ws://<overlay-ip>:6768, source port P1.
3. T+10min — B's Orca was restarted for an unrelated reason, forcing both sides to re-establish.
4. After that, A's connection to the removed endpoint came back with a new source port P2, numerically adjacent to the source port of the surviving Tailscale connection — i.e. both were opened in the same batch. A new source port means a new connection: the removed environment actively reconnected ~10 minutes after it was deleted from disk.

Control

B's Orca main process started after I had removed the mirror-image environment on B's side. B therefore booted with only one environment in memory, and it opened zero connections over the overlay path. Same build, same topology; the only difference is whether the environment was in memory when it was removed.

The endpoint is not on disk any more

I grepped the whole ~/Library/Application Support/orca tree for the overlay address. The only configuration-shaped hit is profiles/local-default/orca-data.json → .sshTargets[N].host, which belongs to the SSH-targets feature — not a WebSocket endpoint, not port 6768. orca-environments.json contains only the surviving endpoint. So ws://<overlay-ip>:6768 exists nowhere on disk, and the connection can only come from in-process state.

Note for anyone reproducing this: other files in that tree matched the address as well — terminal-history/*/checkpoint.json, ai-vault/session-parse-cache.json, agent-hooks/last-status.json. Those are recorded terminal scrollback of my own commands, not configuration. Judge a hit by its path inside the JSON, not by the file name.

How can we reproduce it?

1. Pair client A to server B's runtime twice, over two addresses that are both reachable. You now have two environments whose runtimeId is identical.
2. On B: lsof -nP -iTCP:6768 shows connections arriving over both paths.
3. On A: orca environment rm --environment <the second one>. Confirm orca environment list no longer lists it.
4. lsof again on B: the connection over the removed path is still established.
5. Force a reconnect (restart B's Orca, or drop the link). The removed environment comes back with a new source port.
6. Restart A's Orca: only now is it actually gone.

Anything else that might help

Why this is worth fixing beyond tidiness:

• orca environment list is the supported way to see what is saved, and it disagrees with what is connected. There is no in-app way to notice the difference.
• Someone who removes a server to stop it reaching their machine will reasonably believe it stopped.
• It compounds the duplicate-workspace behaviour: after removing the redundant environment nothing visibly changes until a restart, which invites people to keep removing things looking for an effect.

Suggested fix: when an environment is removed, close its transport and drop it from the in-memory reconnect set, so environment list and the live connection agree.

No endpoint credentials or pairing material are included in this report.