[Bug]: T3 Connect switch stays off after startup restores the tunnel

Before submitting

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

Area

apps/web

Steps to reproduce

1. Set up the desktop environment with npx t3 connect, so a managed T3 Connect link is restored on server startup.
2. Restart T3 Code, for example when a Nightly update relaunches the desktop app.
3. Open Settings > Connections while the server is still reconciling the desired T3 Connect link.
4. Wait for the managed tunnel to come online and confirm that T3 Connect health checks or remote access work.
5. Look at the T3 Connect switch again.

Expected behavior

The switch should update to on when startup reconciliation restores the managed tunnel. It should represent the server's current link state, even if the first read happened before reconciliation finished.

Actual behavior

The switch can stay off after the tunnel is restored and working. This makes it look as though T3 Connect disabled itself after an update or restart.

I captured one occurrence with this order of events:

10:02:31  environment.cloud.readLinkState succeeded
10:02:32  environment.cloud.applyRelayConfig succeeded
10:02:32  environment.cloud.reconcileDesiredLink succeeded
10:03:11  Settings screenshot still showed T3 Connect off
10:04:57  managed T3 Connect health request succeeded
10:05:42  managed T3 Connect health request succeeded

The persisted managed-endpoint runtime configuration was also present from 10:02:32 onward. I redacted the tunnel hostname, tunnel ID, account data, tokens, and local paths.

The source looks consistent with a startup race:

• primaryCloudLinkState.ts reads link state through an SWR atom and exposes an explicit refresh.
• useCloudLinkController.ts renders the switch from managedTunnelActive. Its refresh calls are tied to mutations started by this controller.
• server.ts reconciles CLI-desired T3 Connect state in a parked startup fiber after routes are already available.
• http.ts reports managedTunnelActive from the presence of the runtime configuration.

If the initial link-state request lands just before applyRelayConfig, the atom receives managedTunnelActive: false. I could not find an invalidation when background startup reconciliation changes that state one second later, so the unchecked switch can outlive the stale read.

Impact

Minor bug or occasional failure

Version or commit

T3 Code Desktop Nightly 0.0.34-nightly.20260814.1093, commit 184d8ef33b8f42869fb84f66a33984185b81dc47

Environment

macOS 26.5.2, Apple Silicon, T3 Code Desktop Nightly

Logs or stack traces

No error was reported. Startup reconciliation and later managed-endpoint health checks succeeded.

Screenshots, recordings, or supporting files

A screenshot is available showing Network access on, T3 Connect off, and Publish agent activity on after the managed endpoint configuration had already been restored.

Workaround

Leave the switch alone when remote T3 Connect access still works. Navigating away long enough for the atom to expire, restarting the renderer, or forcing a fresh link-state read should update the display. Toggling the stale switch may provision the link again unnecessarily.

Start with apps/web/src/cloud/primaryCloudLinkState.ts and useCloudLinkController.ts to trace how managedTunnelActive reaches the switch. Then read the startup reconciliation in apps/server/src/server.ts and the response in apps/server/src/cloud/http.ts, and run the relevant web/server tests if available. Done means the switch reflects the restored tunnel after startup reconciliation, including when its initial read happened earlier.