[Bug]: Desktop does not recover network access when Tailscale connects after launch #17362

Before submitting

• Searched existing issues. Related reports are linked below; none found covers the saved Network access preference staying inactive after Tailscale connects later.
• Included the reported sequence, observed configuration, and source analysis.

Area

apps/desktop — Settings → Connections and local backend startup.

Summary

If Tailscale is not connected when T3 Code starts, connecting it after the desktop app is already running does not reliably restore the previously enabled network/Tailscale access. Settings shows Network access off and “Limited to this machine,” even though the saved preference is still enabled. View → Reload does not recover it.

The reporter says restarting T3 Code after Tailscale is connected restores access. This should recover without requiring a restart of the local backend and potentially interrupting running agents.

Steps to reproduce

Reported sequence:

1. Previously enable Network access in the desktop app. Tailscale HTTPS was also enabled in this instance.
2. Launch T3 Code while Tailscale is disconnected/not yet available.
3. Connect Tailscale after T3 Code is already running.
4. Open Settings → Connections for the local environment.
5. Network access remains off and says “Limited to this machine.” Tailscale HTTPS also remains off.
6. Use View → Reload. The access state still does not recover.
7. According to the reporter, quitting and reopening T3 Code with Tailscale already connected restores access.

Important reproduction condition from the source: the startup fallback requires no usable LAN address and no Tailscale IPv4 address at startup. Tailscale being disconnected alone should not trigger that fallback if a usable LAN address is already present. The original startup interface snapshot was not captured, so this condition is a likely explanation to verify rather than an independently reproduced fact.

Expected behavior

Previously enabled Network access should remain effective, or recover when the required networking becomes available, without requiring a manual app restart.

If Tailscale HTTPS setup cannot complete at startup, its saved preference and setup failure should remain visible, with a way to retry when Tailscale connects.

Actual behavior and diagnostics

The screenshot supplied by the reporter shows:

• Local environment enabled.
• Network access off, with “Limited to this machine.”
• Tailscale HTTPS off, with the setup description.
• Desktop/server version 0.0.46-nightly.20261007.2774.

Read-only inspection of this instance found:

{
  "savedPreferences": {
    "serverExposureMode": "network-accessible",
    "tailscaleServeEnabled": true,
    "tailscaleServePort": 445
  },
  "runningBackend": {
    "host": "127.0.0.1",
    "port": 3773
  }
}

Tailscale CLI diagnostics at the same investigation point showed:

• BackendState: Running.
• This machine online, with a MagicDNS name and tailnet addresses.
• No Tailscale health warnings.
• tailscale serve status --json returned {}: no Serve forwarding configured.

Thus this is more than a stale endpoint label: the backend is actually bound to loopback while the saved Network access preference remains enabled. The missing HTTPS mapping is an additional observed symptom of the late-connect sequence.

Code investigation

Source inspected: main @ d81afa0a6f403bd6e5562ffcee2484089a1fdc3f.

• DesktopServerExposure.resolveRuntimeState falls back to local-only when the requested mode is network-accessible but no usable LAN or Tailscale IPv4 address is found. It preserves the requested preference.
• DesktopApp startup calls configureFromSettings before starting the backend.
• getAdvertisedEndpoints reads current interfaces but retains the previously resolved exposure state; it does not restore the backend binding.
• The existing fallback test explicitly verifies loopback binding while the saved preference remains network-accessible. Recovery after interfaces become available is the missing behavior.
• Tailscale Serve setup runs at backend startup and catches setup failures as warnings; no retry for a later Tailscale connection was found.

Related issues

• [Bug]: Connections keeps stale network endpoints after reopening settings #15751: stale Connections endpoint cache after Tailscale connects. Related, but refreshing the renderer does not change an already loopback-bound backend.
• [Bug]: Tailscale Serve failures are only logged as a warning; the server silently stays loopback-only #16238: Tailscale Serve setup failures are not retried. Its macOS follow-up describes a saved enabled flag with inactive Serve and recovery after restarting.
• Tailscale HTTPS shows off and cannot be disabled in Settings when local DNS fails #14746: HTTPS switch reflects a failed probe rather than the saved preference, and confirming Enable can be a no-op. Its reported trigger is DNS failure.

The primary missing behavior in this report is recovery of saved network access after networking/Tailscale becomes available during an existing desktop session.

Impact

Minor bug or occasional failure. Remote access stays unavailable until a restart, and restarting a desktop-hosted backend can interrupt agents, terminals, and remote clients.

Version or commit

T3 Code Nightly 0.0.46-nightly.20261007.2774; source analysis against main at d81afa0a6f403bd6e5562ffcee2484089a1fdc3f.

Environment

macOS 26.6.2, Apple Silicon (arm64), desktop-hosted backend, Tailscale connected after launch.

Workaround and verification limits

The reporter identifies restarting T3 Code with Tailscale already connected as the workaround. View → Reload did not help.

Investigation used the supplied screenshot, read-only configuration/diagnostics, and source inspection. No controlled launch/reconnect reproduction, app restart, settings edits, or manual Serve configuration was performed during the investigation. Private hostnames, tailnet addresses, credentials, and raw logs are omitted.