Windows relay orphans are findable; the superseded sweep declines to look, silently

Found during an adversarial cross-platform pass over nwparker/ssh-remote-integration-stack (798a37bcba2). Report only — no fix proposed here, and the code involved is outside that stack's diff.

The sweep returns before it logs

A relay left behind at a different version directory keeps its shells and agents alive forever and is never contacted again. sweepSupersededRelayEndpoints (src/main/ssh/ssh-relay-superseded-endpoints.ts) exists to make that population visible and deliberate rather than silent — its own header says it does not make them recoverable, it names them.

On a Windows host it does not run:

export async function sweepSupersededRelayEndpoints(conn, hostPlatform, options) {
  if (isWindowsRemoteHost(hostPlatform)) {
    return []
  }

That returns before the listing, before the incumbent probe, and — the part that matters — before any log line. A Windows host produces no findings and no note saying findings were not attempted. In the connect log, "this host had no orphans" and "we did not look on this host" are the same bytes.

The usual justification does not hold

The reason given for skipping is that a Windows relay binds a named pipe rather than a filesystem socket, so the ls-based sweep has nothing to walk. That is true of the POSIX sweep's mechanism. It is not true that the orphans cannot be found.

Named pipes are enumerable without privilege. Measured on a Windows 10.0.26200 host from an ordinary user shell over SSH:

[System.IO.Directory]::GetFiles('\\.\pipe\')
# TOTAL_PIPES=279
# ORCA_PIPES=4
#   \\.\pipe\orca-terminal-host-v36-14cb7f94b511
#   \\.\pipe\orca-20812-24c3
#   \\.\pipe\orca-19488-d3bd
#   \\.\pipe\orca-terminal-host-v36-992f782ecd0d

(No orca-relay-* entries on that host because it is used as an orca-server environment, not an SSH relay target — the enumeration itself is the point.)

And the repo already ships the classifier for the relay ones — isWindowsRelayPipePath() in src/main/ssh/ssh-relay-endpoints.ts matches exactly \\.\pipe\orca-relay-<20 hex>. Enumeration plus classification is available today.

What genuinely does not survive

The mapping back to a version directory. relayEndpointForHost derives the name as sha256(remoteDir + "\0" + sockName).slice(0, 20), and remoteDir carries the version folder. So a discovered pipe proves a relay of some build is listening, but the name alone cannot say which ~/.orca-remote/relay-<version> produced it.

Recovering that needs the other direction, and that code already exists: list the version directories under the remote home, hash each with this target's sockName, check the results against the enumeration. remote-install-gc.ts already does exactly this hashing for its liveness probe, via windowsRelayPipePathsForSocketName.

If picked up, two separate changes in cost order

1. Say so. Log that the sweep was skipped on this host, so an operator can tell "no orphans" from "did not look". Cheap, and it removes the silence that makes everything above hard to notice in the first place.
2. Look. Enumerate the remote's version directories, hash each against this target's sockName, probe those pipe paths for an incumbent — using the same live / unverifiable / exited vocabulary the POSIX sweep already uses (docs/reference/ssh-execution-boundary.md). Loss of contact with a pipe is not evidence the relay behind it exited.

Adjacent, and explicitly not measured

RelaySocketOwnership.listen() skips the umask(0o177) step for named-pipe paths (isRelayNamedPipePath), so on POSIX the socket mode is the access control and on Windows nothing Orca chose is. libuv's uv_pipe_bind passes NULL security attributes, so the pipe takes the creating token's default DACL — but that is reasoning, not a measurement. Get-Acl on a libuv-created pipe fails with error 231 (ERROR_PIPE_BUSY) and the follow-up call then reports the path as nonexistent, so the descriptor was not readable that way. Anyone picking this up should treat the DACL as unknown.

What is measured is that the pipe name is not a secret: any local process enumerates it, as above.

Start with sweepSupersededRelayEndpoints in src/main/ssh/ssh-relay-superseded-endpoints.ts, then read isWindowsRelayPipePath in src/main/ssh/ssh-relay-endpoints.ts and the hashing logic in remote-install-gc.ts. Confirm the existing live, unverifiable, and exited vocabulary in docs/reference/ssh-execution-boundary.md. Done means Windows skips are logged distinctly, and the sweep can enumerate and evaluate matching version-directory relay pipes without treating lost contact as proof of exit.