You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
T3 Connect environment credential remains invalid after clean relink on 0.0.34 nightly #8112
T3 Connect returns The environment credential is invalid when the client machine connects to the host machine, even after a complete unlink/relink with matching versions.
This appears to reproduce #5712 on a newer nightly.
Versions
Client machine: 0.0.34-nightly.20260824.1176
Host machine/CLI: 0.0.34-nightly.20260824.1176
cloudflared: 2026.5.2
Host OS: Windows
Steps to reproduce
Unlink the host machine with npx t3@nightly connect unlink.
Environment ID is available privately to maintainers if needed.
The host reports T3 Connect desired link reconciled on startup, followed by four successful Cloudflare QUIC tunnel registrations. This indicates that the managed tunnel is healthy and the failure occurs during the credential/bootstrap exchange.
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
Updated both host and macOS client to the exact same nightly.
Repaired the background service with t3 service install.
Verified:
t3code.service is active
Linger=yes
local server listens on 127.0.0.1:3773
Performed a full Connect credential reset, not only unlink/relink:
t3 connect logout
t3 connect
systemctl --user restart t3code.service
Fresh authorization completed successfully. t3 connect status then reported:
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:
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.
Activity
Steve-XYZ commentedon Sep 24, 2026
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
26100.92782.7.11.0, kernel6.18.33.2-20.0.43-nightly.20260924.22000.0.43-nightly.20260924.22002026.5.2Clean repro / reset performed
t3 service install.t3code.serviceis activeLinger=yes127.0.0.1:3773t3 connect logout t3 connect systemctl --user restart t3code.servicet3 connect statusthen reported:Actual behavior
Before the full credential reset, clients repeatedly showed:
After the clean
connect logout+ fresh authorization + new environment registration, the environment is rediscovered but the failure changes to:Latest mobile Trace ID:
Earlier
endpoint_request_failedTrace IDs:Isolation / evidence
The local server is healthy:
and returns the current environment descriptor with:
From the macOS client, the managed public environment endpoint is reachable end-to-end through Cloudflare:
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:There were intermittent QUIC transport warnings in WSL (
sendmsg: network is unreachable), so I also forced cloudflared to HTTP/2: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.