[Bug]: Service update leaves T3 Connect relay targeting stale origin port

Before submitting

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

Area

apps/server

Steps to reproduce

1. Run T3 Code as the installed user systemd service on a remote Linux VM and expose it through T3 Connect.
2. Upgrade the desktop app and allow the managed VM runtime/service to update. In this case, the macOS desktop app was 0.0.33, the shell CLI remained 0.0.32, and the managed runtime had installed 0.0.33.
3. Attempt to reconnect to the remote environment from the desktop app.
4. Inspect t3 service status, listeners, and boot-service.log.

The service reported needs an update or repair. The active T3 server listened on 127.0.0.1:3773, while the existing managed Cloudflare tunnel continued forwarding to an old ephemeral origin port (127.0.0.1:35765).

Expected behavior

A managed runtime/service update should atomically restart or reconcile the background service and relay connector. The tunnel origin should always point to the currently active T3 server port, and saved clients should reconnect without manual operator intervention.

Actual behavior

The desktop app could not connect and repeatedly displayed:

Failed to connect. Reconnecting...
Reason: Relay environment endpoint is unavailable: endpoint_request_failed

The relay itself was provisioned and t3 connect status showed exposure enabled, but Cloudflared repeatedly failed to reach its stale origin. The server logs also showed invalid saved-session/bootstrap credentials during reconnect attempts.

Impact

Blocks work completely

Version or commit

Desktop app 0.0.33; managed VM runtime/service 0.0.33; shell CLI 0.0.32 before repair

Environment

macOS desktop client connecting to a Linux Coder VM over T3 Connect; Node v24.19.0; user-level systemd service

Logs or stack traces

$ t3 service status
T3 Code service
  Status: needs an update or repair
  Next: Run `npx t3@latest service update`.

$ ss -lntp
LISTEN 127.0.0.1:3773  # active T3 server

cloudflared: Unable to reach the origin service: dial tcp 127.0.0.1:35765: connect: connection refused

Workaround

Run npx t3@latest service update with access to the user systemd bus, then explicitly restart t3code.service. After restart, T3 0.0.33 listened on port 3773, Cloudflared was relaunched against the live origin, and an outside-in relay health request returned HTTP 200.

One additional wrinkle: from a non-interactive Coder SSH shell, the first service repair could not access the user systemd bus (Failed to connect to bus: No medium found). Setting XDG_RUNTIME_DIR=/run/user/$(id -u) and DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus allowed the service command to inspect the installed unit. This may be worth handling or surfacing explicitly.

Start in apps/server and reproduce the update path with t3 service status and t3 connect status, then inspect boot-service.log alongside the active listener and Cloudflared origin. Done means a managed service update reconciles the relay with the current server port, reconnects saved clients without manual restart, and handles or clearly reports the user systemd bus environment issue.