[Bug]: Tailscale HTTPS cannot be enabled when using the WSL-only backend

[jeremy-]

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. Install and connect the native Windows Tailscale client.

2. Ensure MagicDNS and HTTPS certificates are enabled for the tailnet.

3. Start T3 Code on Windows.

4. In Settings → Connections:

   • Enable Network access.
   • Select an Ubuntu WSL backend.
   • Enable WSL only.

5. Enable Tailscale HTTPS on port 443.

6. After T3 Code returns, run the following in Windows PowerShell:

   tailscale serve status

7. Attempt to open the advertised Tailscale HTTPS endpoint or create a Tailscale sharing link.

Expected behavior

Note: This issue content was generated by Codex after I confirmed I was able to manually resolve my issue.

T3 Code should configure the native Windows Tailscale daemon to proxy the active WSL-backed T3 server, equivalent to:

tailscale serve --bg --https=443 http://127.0.0.1:3773

The HTTPS endpoint should become reachable, and the Tailscale HTTPS control should reflect the applied configuration.

Actual behavior

The desktop app discovers and displays the correct MagicDNS HTTPS hostname, but no Tailscale Serve configuration is created.

After attempting to enable it:

• The desired setting is persisted as enabled.
• tailscale serve status still reports No serve config.
• The advertised HTTPS endpoint is unreachable.
• No relevant Tailscale command error appears in the desktop or WSL backend logs.
• Subsequent Enable attempts do not relaunch or retry because the setting is already persisted as enabled.

Source investigation suggests this is specific to WSL-backed operation:

• The Windows Electron process discovers the hostname using the native Windows tailscale.exe.

• The normal backend configuration forwards tailscaleServeEnabled.

• resolveWslStartConfig, however, explicitly sets:

  tailscaleServeEnabled: false
  tailscaleServePort: 443

Source:
https://github.com/pingdotgg/t3code/blob/ecb35f758399/apps/desktop/src/backend/DesktopBackendConfiguration.ts#L397-L414

The relaunch decision also depends only on whether the persisted setting changed. Once it is saved as true, there is no reconciliation/retry path:
https://github.com/pingdotgg/t3code/blob/ecb35f758399/apps/desktop/src/backend/DesktopServerExposure.ts#L489-L520

This appears related to #2830, but it has a different cause. In this case HTTPS certificates are enabled and tailscale serve succeeds when invoked manually; the command is never attempted by T3 Code while WSL-only is active.

Impact

Major degradation or frequent failure

Version or commit

T3 Code 0.0.29-nightly.20260715.816 Commit ecb35f7

Environment

Windows 11 24H2 T3 Code Desktop Nightly 0.0.29-nightly.20260715.816 WSL 2 with Ubuntu 24.04 WSL backend enabled WSL-only mode enabled Native Windows Tailscale 1.98.4 Tailscale MagicDNS and HTTPS certificates enabled T3 backend listening through the Windows WSL relay on 127.0.0.1:3773

Logs or stack traces

Before the workaround:

 > tailscale serve status
 No serve config

 The T3 desktop trace records successful
 desktop.serverExposure.setTailscaleServeEnabled calls, but no corresponding
 Tailscale Serve command is emitted by the WSL backend.

 The WSL server starts with:

 server.mode: desktop
 server.port: 3773
 server.host: 0.0.0.0

 The Windows loopback relay successfully returns HTTP 200 from:

 http://127.0.0.1:3773/.well-known/t3/environment

Screenshots, recordings, or supporting files

No response

Workaround

Running the intended proxy command manually in Windows PowerShell resolves the issue:

tailscale serve --bg --https=443 http://127.0.0.1:3773

**Afterward:**

https://<device>.<tailnet>.ts.net (tailnet only)
|-- / proxy http://127.0.0.1:3773

The HTTPS discovery endpoint returns HTTP 200, T3 Code automatically shows the Tailscale HTTPS control as enabled, and a generated Tailscale sharing link works successfully from another device on the tailnet.

The workaround remains active across Tailscale restarts, provided T3 continues using local port 3773.

## Suggested implementation direction

I would keep this concise in the issue rather than prescribing a large redesign:

```markdown
A possible fix is for the Windows desktop process to own Tailscale Serve reconciliation in WSL-only mode:

1. Wait until the WSL backend and Windows loopback relay are ready.
2. Run the native Windows `tailscale.exe serve` command against `127.0.0.1:<active-port>`.
3. Reconcile desired versus applied state on startup, rather than only acting when the persisted setting changes.
4. Surface command failures in the UI, as also requested by #2830.
5. Disable the mapping when the user disables Tailscale HTTPS.

Passing the setting directly into the Linux backend may be undesirable because it could use a separate WSL Tailscale installation/node rather than the native Windows daemon.