[Bug]: T3 Connect reports "relay offline" when the local clock isn’t NTP-synced (health JWT 401; tunnel is up) #7435

Before submitting

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

Area

apps/server

Steps to reproduce

1. Desktop app on Windows, T3 Connect linked, managed Cloudflare tunnel running (cloudflared tunnel run).
2. Disable automatic time (W32Time stopped / “Set time automatically” off) so the machine uses CMOS and can drift >60s from real time.
3. Open [app.t3.codes/settings/connections](https://app.t3.codes/settings/connections).

Expected behavior

environment shows online, or a clock-skew error.

Actual behavior

row stays relay offline. Tunnel is healthy:

• GET https://<allocation>.t3coderelay.com/.well-known/t3/environment → 200
• Relay worker POST /api/t3-connect/health reaches the server (cf-worker: t3.codes) and gets 401

EnvironmentHttpUnauthorizedError: Invalid cloud health request.
http.route=/api/t3-connect/health
http.response.status_code=401

cloudEnvironmentHealthHandler (apps/server/src/cloud/[http.ts](c:\Work\Dopppler\dopppler\apps\server\src\cloud\http.ts)) verifies t3-cloud-health+jwt with clockTolerance: 60 / CLOUD_PROOF_CLOCK_SKEW_SECONDS = 60, then folds all verify/claim failures into that one 401. jose time-claim failures are indistinguishable from a bad mint key or sub mismatch. Connections treats 401 as offline.

Confirm: w32tm /query /status → Source: Local CMOS Clock, Last Successful Sync Time: unspecified. After w32tm /resync (or turning automatic time on) the same environment goes online with no relink.

Impact

Blocks work completely

Version or commit

0.0.34-nightly.20260818.1127 (Windows desktop). Reproduced 2026-08-18.

Environment

Windows 10.0.26200, T3 Code Nightly, managed tunnel to 127.0.0.1:3773. Account had 2 hosts (under the 3-tunnel cap).

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Sync Windows time to NTP, keep W32Time Automatic. Relink is unnecessary if clock was the only problem.

Suggested fix

1. Don’t map JWT date-claim failures to generic Invalid cloud health request. Surface clock_skew (local now vs token iat/exp) in t3 connect status and Connections.
2. Fail fast with that reason instead of “offline”.
3. One-liner in Connect docs: Windows needs automatic/NTP time; skew >60s makes the host look down.