[Bug]: Tailscale connect completely broken after recent nightly update #9869

Activity

1. fuzzyhope1502

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 5, 2026
2. juliusmarminge commented on Sep 5, 2026

   

   juliusmarminge

   on Sep 5, 2026

   Member

   More actions

   I traced this on current main 7f8cf30c. The quoted error is from fetching the remote environment descriptor before authentication. An owned local HTTP server succeeds through that same client code; resetting the connection produces the reported Transport-error shape. That narrows the stage, but does not reproduce your desktop/Tailscale failure, so I am keeping this open.

   Please share the desktop OS, exact nightly build and remote server version, whether the connection is direct/relay/tunnel, and the URL scheme and port. The native app’s DevTools Network entry for the failed descriptor request would be especially useful: the underlying net error and relevant CORS response headers. Redact pairing tokens, cookies and authorization headers. Opening a URL in the browser address bar does not exercise the same cross-origin fetch restrictions as the app.

   No updates, network configuration or Tailscale settings were changed during this check. GPT 6 Astra via Codex in T3 Code.
3. juliusmarminge commented on Sep 5, 2026

   

   juliusmarminge

   on Sep 5, 2026

   Member

   More actions

   Thanks for the report. This is a real desktop/renderer fetch failure, not a Tailscale outage.

   What the two symptoms are

   1. After the nightly, remotes stuck on something like “Finalizing Update” is the reconnect-through-version-skew banner. Current copy is “Finishing an update” on a Connecting/Reconnecting environment (apps/web/src/components/ChatView.tsx). The client has already moved on; it is waiting for the remote to come back on a matching version.

   2. After you updated the remote server, the quoted error is the pre-auth descriptor GET, before pairing tokens or session cookies are used:

      Failed to fetch remote environment endpoint http://domain/.well-known/t3/environment (HttpClientError: Transport error (GET …))

      That string is built in packages/client-runtime/src/rpc/http.ts when fetch() throws and no HTTP response is attached. Chromium reports CORS / mixed-content / local-network blocks the same way: TypeError: Failed to fetch → Effect TransportError. Opening the URL in a browser address bar does not exercise that path.

   The request is a direct GET to the saved environment HTTP origin. It is not a T3 Connect relay call. Tailscale only supplies that origin (http://<tailnet-ip>:<port> or https://<host>.ts.net/ via Serve).

   Likely root cause (same as #8878)

   #8878 is the same Transport-error + “browser/curl works, desktop does not” shape on Tailscale Serve. Since 0.0.34 (#5877), the CLI inlines effect but leaves @effect/platform-bun external. A Bun-run server loads two effect copies. CORS preflight still works (answered inline), but Access-Control-Allow-Origin is never attached to the real GET, so the desktop origin t3code://app (CORS-enabled, secure: true) discards it.

   That is still the packaging on current main (scripts/lib/cli-external-packages.ts still externalizes @effect/platform-bun). In-process Node tests cannot see it; an owned local Node HTTP server also cannot. That matches the earlier check on 7f8cf30c.

   The open fix is #9118. Live Bun-vs-Node checks there already restore Access-Control-Allow-Origin: *, gzip, and pairing Set-Cookie.

   Uninstalling both sides does not help if the remote is reinstalled under Bun (bun add t3 / --ignore-scripts). The iOS/native client would still work because it does not enforce CORS.

   Workaround while #9118 is open

   On the remote host, reinstall and run the server under Node (not Bun). #8878 confirmed 0.0.37 under Node serves the desktop client again. Keep --host / --tailscale-serve as you had them.

   Quick check on the remote (redact hostnames):

   # which runtime?
   ps aux | grep -E '[t]3|[b]in.mjs'
   
   curl -sD- -o /dev/null -H 'Origin: t3code://app' \
     http://127.0.0.1:<port>/.well-known/t3/environment | grep -i access-control

   • Bun-run 0.0.34+: OPTIONS still has Access-Control-Allow-Origin: *; GET does not.
   • Node-run: GET should include Access-Control-Allow-Origin: *.

   Please send (redact tokens / cookies / auth headers)

   • Desktop OS and exact nightly / client version
   • Remote install method and runtime: node vs bun, and t3 --version
   • How the remote is published: --tailscale-serve (HTTPS .ts.net) vs --host <tailnet-ip> (HTTP)
   • The two curl header dumps above from the remote (GET and OPTIONS)
   • If you can: DevTools → Network for the failed /.well-known/t3/environment request (status, CORS headers, any net error)

   If GET already has Access-Control-Allow-Origin and the client still fails, we will look at Chromium local-network access on 100.64/10 and HTTP-from-t3code:// next. The #8878 header miss is the first thing to rule out.

   No network, Tailscale, or update settings were changed during this check.
4. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 5, 2026