T3 Connect environment credential remains invalid after clean relink on 0.0.34 nightly #8112

Activity

1. Steve-XYZ commented on Sep 24, 2026

   

   Steve-XYZ

   on Sep 24, 2026 – with ChatGPT Codex Connector

   More actions

   Reproduced on the current nightly with a stronger isolation of the failure. This is still present on 0.0.43-nightly.20260924.2200 after a full T3 Connect credential reset.

   Environment

   • Host: Windows 11 build 26100.9278
   • WSL: 2.7.11.0, kernel 6.18.33.2-2
   • Guest: Ubuntu 26.04 LTS, systemd user service
   • T3 host/CLI: 0.0.43-nightly.20260924.2200
   • macOS client: 0.0.43-nightly.20260924.2200
   • cloudflared: 2026.5.2
   • Also reproduced from T3 mobile against the same environment

   Clean repro / reset performed

   1. Updated both host and macOS client to the exact same nightly.
   2. Repaired the background service with t3 service install.
   3. Verified:
      • t3code.service is active
      • Linger=yes
      • local server listens on 127.0.0.1:3773
   4. Performed a full Connect credential reset, not only unlink/relink:

      t3 connect logout
      t3 connect
      systemctl --user restart t3code.service

   5. Fresh authorization completed successfully. t3 connect status then reported:
      • Exposure: enabled
      • Authorization: stored credential
      • Environment link: provisioned
      • Relay: https://relay.t3.codes
   6. Service logs showed:

      T3 Connect desired link reconciled on startup
      Relay client tunnel connection registered
      Relay client tunnel connection registered
      Relay client tunnel connection registered
      Relay client tunnel connection registered
      

   7. Attempted connection again from both macOS and mobile.

   Actual behavior

   Before the full credential reset, clients repeatedly showed:

   Relay could not reach the environment endpoint (endpoint_request_failed)
   

   After the clean connect logout + fresh authorization + new environment registration, the environment is rediscovered but the failure changes to:

   Connection failed. Reason: The environment credential is invalid.
   Hint: Check that automatic date and time is enabled on both devices, then try again.
   

   Latest mobile Trace ID:

   ce37e16454aca162c5347888aaa3403f
   

   Earlier endpoint_request_failed Trace IDs:

   31ea04d6d4d9a16baf09a2f9ae420b6e
   4774bce7467e656a58d05deb855642fa
   

   Isolation / evidence

   The local server is healthy:

   LISTEN 127.0.0.1:3773
   

   and returns the current environment descriptor with:

   "serverVersion": "0.0.43-nightly.20260924.2200"

   From the macOS client, the managed public environment endpoint is reachable end-to-end through Cloudflare:

   GET https://<managed-endpoint>/.well-known/t3/environment
   HTTP/2 200
   

   The returned descriptor is the same current environment and current nightly.

   The T3 Connect server endpoints are also reachable through the managed tunnel. Sending unauthenticated empty requests from macOS reaches the host and returns an application-level 400, not a Cloudflare/tunnel error:

   POST /api/t3-connect/health           -> HTTP/2 400
   POST /api/t3-connect/mint-credential  -> HTTP/2 400
   

   There were intermittent QUIC transport warnings in WSL (sendmsg: network is unreachable), so I also forced cloudflared to HTTP/2:

   [Service]
   Environment="TUNNEL_TRANSPORT_PROTOCOL=http2"

   After restart, all four tunnel registrations are consistently protocol=http2. The invalid-environment-credential failure remains unchanged.

   This rules out the local server being down, a stale origin port, client/server version skew, and basic reachability of the managed tunnel. The failure appears to be in the T3 Connect environment credential/bootstrap exchange after the environment is provisioned.

   For comparison, T3 Connect from the same mobile client to a different MacBook environment on the same account works normally, so the account/mobile Connect path itself is functional.

   Environment ID can be provided privately if useful.