[Bug]: cloudflared left by a server that died keeps serving the T3 Connect tunnel #21701

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

Server — T3 Connect managed relay client (cloudflared)

Steps to reproduce

1. Enable T3 Connect with a managed tunnel and wait for Relay client process started.
2. Kill the server without letting it run finalizers: kill -9 <server pid> (same for a crash, an OOM kill, or a force-quit of the desktop app).
3. ps -o ppid,pid,lstart,command -p $(pgrep -f 'cloudflared tunnel'): cloudflared is still running, reparented to pid 1.
4. Start the server again.

Expected behavior

The new server stops the relay client left behind by the dead server (only if it is still the same process), then starts its own.

Actual behavior

A second cloudflared starts and the first keeps running. Two connectors now serve one tunnel. The orphan is invisible to T3 (it is not in the runtime's active connector), keeps the token it started with, and runs until the user finds and kills it by hand.

Impact

Every unclean server exit leaks one cloudflared process that keeps serving the tunnel. We saw this on macOS desktop builds (Oct 2026) after a server crash; one orphan also survived for good when its recorded start time changed with the DST switch in our local workaround, so the process identity must be time-zone independent.

Version or commit

Reasoned from main at 1451e7cb: apps/server/src/cloud/ManagedEndpointRuntime.ts spawns the connector into connectorScope with detached: false and stops it only through scope finalizers (stopConnector, or runtime.applyConfig(null) in the runtime finalizer). Nothing records the connector across server lives; apps/server/src/cloud/ has no pid file, ledger or orphan sweep.

Environment

macOS, T3 Code desktop with T3 Connect (managed tunnel). The code path is the same on Linux.

Logs or stack traces

None beyond the ps output above.

Workaround

Kill the leftover cloudflared by hand.

The same class of problem was solved for OpenCode servers by OpenCodeServerLedger (#13879, #5241): record each spawned server with its owner's identity and reap entries whose owner is gone. A fix following that pattern for the relay client is in #21702.