Open in editor: allow configuring the advertised SSH host instead of <hostname>.local

[SpyrosPsarras]

Problem

"Open in VS Code" from a browser/desktop client against a headless t3 serve host only ever offers two SSH targets, computed server-side in RemoteOpenTargets (packages/server/.../remoteOpenTargets): the Tailscale MagicDNS name, else <os.hostname() first label>.local.

On a LAN/VPN setup without Tailscale and without mDNS, the button produces vscode://vscode-remote/ssh-remote+t3code.local/..., which no client can resolve:

• the host is a Debian LXC with no avahi, so t3code.local never answers on the LAN;
• mDNS does not cross WireGuard, so remote clients fail even if it did;
• the host already has a proper DNS name (t3code-ssh.example.com) that every client, on any machine, resolves through the internal DNS.

Today the only workaround is a Host t3code.local alias in ~/.ssh/config on every client machine.

Related but different: #7530 (same-machine LAN IP classified as remote), #8278 (Docker hop). Both are about whether the SSH path is taken; this one is about which host it advertises.

Proposal

Let the operator name the advertised SSH host, e.g. a --remote-open-host <fqdn> flag on t3 serve or a T3CODE_REMOTE_OPEN_HOST env var (fits the existing T3CODE_HOST pattern for the background service drop-in). When set, it becomes the first RemoteOpenTarget (a new kind "configured", or reuse "tailscale" semantics of "reachable from anywhere"), ahead of the auto-detected tailnet/mDNS targets.

Optionally also accept a user@host form so the deep link can carry the SSH user.

Version: t3@0.0.38, Linux host (Debian 13 LXC), background service.

[terryds]

Adding a second case here per the close on #10906, plus a concrete option for the fix.

Case: T3 server on an exe.dev VM (machine hostname myvm, sshd on, no Tailscale), client on a home network paired via https://myvm.exe.xyz. "Open in VS Code" fires vscode://vscode-remote/ssh-remote+myvm.local/... and VS Code fails with "Could not resolve hostname". Same ~/.ssh/config alias workaround as above.

Option: prefer the hostname the client paired through. The client already holds a name it has proven it can reach. resolveRemoteOpenState in apps/web/src/remoteOpen.ts parses that URL's hostname only for the loopback check, then discards it and takes the first advertised target.

Proposed precedence:

1. Desktop SSH alias (as today)
2. Hostname of the paired URL (BearerConnectionProfile.httpBaseUrl, or the primary target URL in a browser)
3. Advertised targets, Tailscale then mDNS (as today)

Keep an empty advertised list as "No SSH route" so a server without sshd is unchanged. Relay and T3 Connect targets have no direct URL and keep today's behavior. LAN IPs work as SSH hosts, so LAN pairings benefit too. Client-only change in remoteOpen.ts plus tests, no contract or server change, no operator config.

Where it falls short: an HTTP-only tunnel hostname in front of the server (Cloudflare tunnel, ngrok) would be preferred and then fail on SSH. The --remote-open-host flag proposed above covers that case, and a configured host could simply slot in ahead of the paired one. The two compose rather than compete.

Happy to send a PR for the paired-hostname change, or for the flag, whichever the maintainers prefer.

[HaukeSchnau]

I hit the same wall on a headless NixOS host where sshd sits on a non-default port and the tailnet name is not what clients have in their ~/.ssh/config, so I built the proposal above as described: a T3CODE_REMOTE_OPEN_HOST server setting that is advertised as a single configured target and skips the sshd/tailscale probes. Pointing it at an ssh config alias lets the viewer's own ~/.ssh/config supply user, port, key and ProxyCommand, which a bare hostname can never carry, so it also covers the user@host angle without a new wire format.

I will open a PR against main shortly, plus a separate one that lets browsers pick VSCodium, Cursor or Zed in remote mode instead of hardcoding VS Code. The "prefer the paired hostname" idea from #10906 could still be a sensible fallback behind the configured host; I left it out to keep the change small.