[Bug]: Browser panel: Local servers / Recently used open the server's IP instead of localhost, breaking loopback-only dev servers (WSL2)

[jaaneh]

Before submitting

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

Area

apps/desktop

Steps to reproduce

1. Run T3 Code in WSL2 so the server listens on all addresses, and connect to it from Windows at the WSL IP.
2. In WSL, start a dev server that listens only on loopback. For example, npx vite --port 3001 binds to 127.0.0.1:3001.
3. Open the Browser panel in a thread.
4. Click localhost:3001 under Local servers. Clicking it under Recently used gives the same result.

Expected behavior

The panel opens http://localhost:3001/ and the page loads. This URL works from Windows because WSL2 forwards localhost.

Actual behavior

The panel opens http://172.24.66.27:3001/ and fails to connect, because the dev server doesn't listen on that address. Typing localhost:3001 into the address bar loads fine; only the list entries are rewritten.

Impact

Minor bug or occasional failure

Version or commit

v0.0.43-nightly.20260924.2200

Environment

WSL2

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Either:

• start the dev server listening on all addresses (--host or --host 0.0.0.0), or
• type localhost:<port> into the address bar instead of clicking the entry.

[juliusmarminge]

Confirmed on current main. Clicking Local servers or Recently used rewrites a loopback URL to the environment connection host. Typing the same URL in the address bar does not. With the desktop WSL backend in NAT mode, that host is the distro's eth0 address (172.24.66.27 here), and a server bound only to 127.0.0.1 never accepts it.

172.24.66.27 is in 172.16.0.0/12, so it is treated as a private-network environment rather than loopback. Discovered loopback targets are then rewritten onto that host:

  // Local loopback environments should advertise `localhost` so Chromium
  // dual-stack lookup can reach a Vite server bound only to ::1 or 127.0.0.1.
  const resolvedHost = isLocalLoopbackHost(normalizedEnvironmentHost)
    ? "localhost"
    : normalizedEnvironmentHost.includes(":")
      ? `[${normalizedEnvironmentHost}]`
      : normalizedEnvironmentHost;

resolveDiscoveredServerUrl sends every loopback picker URL through that substitution. Both empty-state lists use it. The address bar uses normalizePreviewUrl only, which is why localhost:3001 typed by hand still loads.

  const handleSubmitUrl = useCallback(
    async (next: string) => {
      try {
        const normalized = normalizePreviewUrl(next);
        if (await navigateToResolvedUrl(normalized)) {
          recordVisitForThread(threadRef, normalized);
        }
      } catch {
        // Server-side `failed` event renders the unreachable view.
      }
    },
    [navigateToResolvedUrl, threadRef],
  );

  const handleOpenServerUrl = useCallback(
    async (next: string) => {
      try {
        const resolved = resolveDiscoveredServerUrl(threadRef.environmentId, next);

The rows still display localhost:3001. The port scanner reports localhost, and history stores the pre-resolution URL. Only the navigation target changes, to http://172.24.66.27:3001/. That split is covered by PreviewView.test.tsx: "preserves a direct localhost URL in a WSL environment" and "maps an empty-state localhost server onto the WSL host" (connection http://172.25.85.75:3773).

The desktop WSL backend does this on purpose. In NAT mode it binds the T3 server to 0.0.0.0 and points the renderer at hostname -I because wslhost's localhost forward is flaky for that server (DesktopBackendConfiguration.ts, rendererHost). Mirrored mode is different: the distro IP matches a Windows interface, so the renderer host stays 127.0.0.1 and this rewrite does not run. 172.24.66.27 means NAT mode.

That NAT URL is the right way to reach the T3 server. It is the wrong way to reach a dev server bound to loopback. From the Windows webview, http://172.x:3001 hits the distro's eth0 address, which a 127.0.0.1-only listener does not accept. http://localhost:3001 still works because Windows localhost forwarding lands on that loopback bind. Rewriting is appropriate for a real remote client opening a server that listens on the environment's reachable interface. It is not appropriate for the default Vite/loopback case on a WSL NAT backend.

Same resolver, same result:

• Sidebar discovered-port clicks (openDiscoveredPort)
• Agent environment-port navigation (resolveBrowserNavigationTarget)

This is the leftover from #3938 / #3939. That fix stopped the address bar from inheriting discovered-server routing and deliberately left empty-state WSL remapping in place. No other open issue covers this list-click path.

The workarounds in the report are the right ones: bind the dev server on all interfaces (--host / 0.0.0.0), or type localhost:<port> into the address bar instead of using the list. Present on v0.0.43-nightly.20260924.2200 and on main; the rewrite has been there since #3939.

[atiqsamtia]

I'm stuck on a reverse of this issue.

I've a Linux environment connected via t3connect but in Browser preview it shows localhost urls for preview which fails as the services are running on a remote Linux instance. Any configuration to set the browser base IP for an environment, or a way to port forward in t3connect?