Repository navigation
[Bug]: T3 Connect managed endpoint provisioning fails repeatedly on Windows 11 #14070
Description
Activity
Triage
This is a hosted-relay provisioning failure, not a Windows client or cloudflared install failure. The report is specific enough to investigate. It is the same client-visible failure as #13681, but not a duplicate: that report was a different environment, closed after a later retry worked with the cause unconfirmed. These four attempts are still failing.
POST /v1/client/environment-linksreturnedenvironment_link_unavailable/managed_endpoint_provisioning_failed. That reason is only produced whenManagedEndpointProvider.provisionfails (infra/relay/src/http/Api.ts). The desktop string matchesrelayProtectedErrorMessageforRelayEnvironmentLinkUnavailableError. By the time provision runs, the link proof has verified, the challenge nonce has been consumed, and the origin has passed the loopback check. A bad proof, a non-loopback origin, an insecure endpoint, or the managed-tunnel cap would be different codes (environment_link_proof_*,origin_not_allowed,endpoint_not_secure,environment_link_limit_exceeded).That also explains why there is nothing useful to deregister. The environment link row is written only after provision returns (
EnvironmentLinker.link). A failure here leaves no Account → T3 Connect registration. Local cloudflared is not on this path either: Settings callsensureRelayClientAvailablebefore the link request, and the connector is started only after the relay returns a tunnel token. A missing binary would be a different client error and would not reach this response. Relay health responding is expected; it is a different route.What this response already rules out:
- Missing relay config. That is
managed_endpoint_not_configured. - The per-account tunnel cap (default 3). A cap hit is
environment_link_limit_exceededand names the maximum. - The 9s relay deadline. That response is a 504
relay_request_deadline_exceeded, and the client would not show this reason. - Open follow-ups that only matter after a link exists: fix(desktop): re-register Connect tunnel origin after backend port hop #12724 (re-register origin after a port hop), fix(server): use listener port for managed tunnel origins #8353 (listener port in the link proof), fix(server): wait for Cloudflare tunnel registration #8352 (wait for
Registered tunnel connection), chore(shared): bump managed cloudflared to 2026.10.0 #11184 (bump managed cloudflared). None of those run before this response.
0.0.42 is still the latest stable desktop release. Updating it will not change this path. The client drops the failure stage. The relay error carries
stageplus hostname, tunnel name, and tunnel id when it has them. Provision stages arederive-environment-hash,check-tunnel-limit(a limit-query persistence error, not the cap),reserve-allocation,ensure-tunnel,validate-tunnel-response,record-tunnel,configure-tunnel,ensure-dns-record,record-dns,get-tunnel-token, andmark-allocation-ready. The span isrelay.managed_endpoint_provider.provision, annotated withrelay.environment_id,relay.managed_endpoint.origin_host, andrelay.managed_endpoint.origin_port. The environment id is not in this report; it is on that span. Please do not reset it. A new id would only hide a wedgedrelay_managed_endpoint_allocationsrow.Please look these up in
t3-code-relay-traces-prodbefore changing code:fe743ccef63184b15eebc7f6d03dae13(initial)58a420de14b2a8e16b258082462bfac8(Settings)b528e164721834faeeb4d9dff930d04c(Settings retry)cf8e4071a1013229da78780a2cd32029(latest)
Each retry got a new trace and the same reason, so this is not a consumed nonce and not a one-off client timeout. The stage distinguishes a Cloudflare create/config/DNS/token error from a stuck allocation whose generation claim no longer matches. Since #9386, an offline host releases its Cloudflare tunnel and the next provision recreates it under the same name; a lost claim is supposed to be retryable. The same stage and environment id across all four traces, with no successful provisions in that window, means the allocation for this environment is wedged rather than a single Cloudflare blip.
- Missing relay config. That is
Also seeing this on macOS, so it isn't Windows-specific.
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed). Trace ID: a8ccbaf9770d93ff3f457945c84cd3ec- T3 Code (Alpha) 0.0.42, macOS 26.3 (arm64), desktop app, Settings → Connections → T3 Connect
- Fresh install with no earlier cloud link state. Port 3773 is held by T3 Code itself.
- Local desktop use still works.
Reacted by Luca Dommes and Germán PinedaI'm also seeing this on Windows with T3 Code 0.0.42. Retrying from Settings → Connections after restarting T3 Code still fails with:
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).Latest trace ID:
b7785eb3b0dd083a3f640595ec3b50ecUpdating the Codex CLI and restarting resolved a separate local Codex detection problem, but T3 Connect provisioning still fails. Could the relay team inspect the failing provisioning stage for this trace?
Same failure here on a fresh install, still happening on today's nightly
- T3 Code
0.0.43-nightly.20260929.2416, Windows 11 Pro build26200 - Fresh install around
2026-09-29 04:00 UTC, so this environment ID is brand new:76cba492-e3e7-4f39-badc-65362074b635 - The very first link attempt failed, so there was no earlier allocation for this environment to get stuck
- Trace ID:
1af09203e14a27c5c078c71c7ce31c6c - Relay client install and
environment.cloud.makeLinkProofsucceed, thenPOST /v1/client/environment-linksreturns HTTP503managed_endpoint_provisioning_failed
The same account has an older environment that provisioned successfully (
75d9c0b7-82ab-4b03-b90a-1e3f95cac11a). That host is offline now and its managed hostname returns Cloudflare530, in case the account's allocations matter- T3 Code
Also reproducing on Linux (Pop!_OS), T3 Code nightly 0.0.43-nightly.20260928.2402, running as a background service (t3code.service), cloudflared 2026.5.2. Not Windows-specific and not nightly-specific.
Reconcile of the desired link has failed continuously since 2026-09-28 15:41 UTC (139 attempts, each 8-11s):
- 97x HTTP 504 (relay 9s deadline). Latest Cloudflare Ray IDs: a42516373955de9f-DAR, a425153c1c96dd97-DAR, a42514428f06dd97-DAR, a42513102f10dea2-DAR, a425125598ebdd97-DAR
- 42x environment_link_unavailable / managed_endpoint_provisioning_failed. Latest trace IDs: 0618d125749dabc501368909af13d00c, ab8782e0578ab62ab7783a278e7a6f61, 354b333d24f6eebe1266db128cc2e26a, 5e39f4981ebc652eaec621ca38fb9d33, 7eb6284989e84899f65b63d0b75c3490
Earlier release-on-shutdown (2026-09-27) failed with upstream_unavailable, trace 39637552dc6da9ea37c4790b668cc2fe, and relay-side unlink returns 500. So the allocation likely went stuck after the #9386 offline-tunnel cleanup. Provisions near the 9s deadline suggest a slow Cloudflare call in ensure-tunnel/configure-tunnel. Environment ID has not been reset. Could you check the stage on relay.managed_endpoint_provider.provision for these traces?
Also reproducing on another Windows environment on September 29, 2026. Adding this here following the consolidation of #14155.
Environment
- T3 Code (Alpha) desktop 0.0.42, installed Windows application.
- Windows 11 Home 25H2, build 26200.8246, x64.
- Environment ID, read from the local
/.well-known/t3/environmentendpoint:6f093da1-b9db-45a9-bf3f-8b5fd3bdd3b7. - Local environment enabled; WSL backend selector shows Ubuntu, with WSL only off.
- Publish agent activity off in both failure screenshots.
Steps to reproduce
- Open Settings → Connections in the desktop app.
- Enable T3 Connect for the local environment.
- The app displays “Could not update T3 Connect” and the error below. The T3 Connect toggle is off afterward.
- Retry several minutes later. The same error appears with a different trace ID.
Expected and actual behavior
Expected: the environment gets a managed endpoint and becomes available to other devices through T3 Connect.
Actual:
https://relay.t3.codes/v1/client/environment-linksfails with:Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).This blocks T3 Connect remote access for this environment. The local app remains available.
Trace IDs and time references
Attempt Trace ID shown by the desktop app Screenshot saved at (UTC) First captured failure 21fca453a6d5ee1c2df9c5ad736ab802026-09-29 21:52:57 Later retry 2cf50453359b9a4763322fe749573b3a2026-09-29 21:58:49 These times come from the screenshot files' creation timestamps, not HTTP request timestamps; the failed requests occurred before the corresponding captures. Local timezone was Europe/Belgrade, UTC+02:00 (23:52:57 and 23:58:49 local).
Checks performed
- The T3 Code process owns the TCP listener on
0.0.0.0:3773. GET http://127.0.0.1:3773/returned HTTP 200.- The local environment descriptor is readable.
- Searching the available local
server.trace.ndjson*anddesktop.trace.ndjson*files did not find this error string or the first trace ID. No client-side stack trace or HTTP response status was captured, so I cannot report a 503/504 for these particular requests. - No environment ID reset, credential deletion, application reinstall, or network configuration change was performed during this investigation.
Workaround
None confirmed. Retrying after several minutes did not resolve the failure.
Could the relay team inspect
relay.managed_endpoint_provider.provisionfor this environment and these traces, particularly the failingstageand underlying cause?Screenshot of the later retry
Update to my earlier report: the suggested deregistration recovery is also failing.
New link error
Enabling T3 Connect now reports:
https://relay.t3.codes/v1/client/environment-links failed: Relay refused the link: this account already has its maximum of 3 managed tunnels. Unlink an environment to free one up. Trace ID: 056d6a99e41d73a2a792f0e6724db3efAccount → T3 Connect shows exactly three environments, all marked "Managed tunnel": my Docker container, MacBook Pro, and this Asus Windows PC. All three are intended to remain in use. The Asus registration shows a linked date of August 30, 2026.
The Windows environment ID previously read from the local descriptor is
6f093da1-b9db-45a9-bf3f-8b5fd3bdd3b7. I have not verified whether the cloud Asus entry has the same ID; matching display names alone do not establish that.Deregister also fails
After attempting the recommended Deregister recovery for the Windows PC, the UI reports:
Could not deregister server Could not unlink relay environment. Trace ID: 2888faa60d95dbdb38c0f1e2bc8a3f8dThe UI did not confirm successful deregistration, so I cannot complete the normal unlink/re-link recovery.
Time references
- Limit-error screenshot saved: September 30, 2026, 03:43:42 UTC.
- Deregister-error screenshot saved: September 30, 2026, 03:50:17 UTC.
These are screenshot file creation times, not exact HTTP request timestamps. Local timezone: Europe/Belgrade, UTC+02:00.
Please check the failed unlink trace as well as the quota trace, and whether the cloud Windows registration matches the current local environment ID. This may involve stale registration/allocation state, but the client messages do not establish the underlying cause. No local environment ID or credential files have been deleted as part of this investigation.
Also seeing this on a Windows host today, enabling T3 Connect from Settings → Connections:
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed). Trace ID: 556d6ae411e3162f2df1708de48345a5- Time: about 2026-09-30 12:32 UTC (screenshot time, not the exact request time)
- Environment ID has not been reset
The environment ID should be on the
relay.managed_endpoint_provider.provisionspan for that trace.Update: Retrying about 15 minutes later worked and the environment linked.
Got the same problem on MacOS
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed). Trace ID: 03839b0cd8eb49385b76303d255d5437
Replicated on macOS 27.0, T3 Code v0.0.44 (installed via macOS download,
.dmg)
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed). Trace ID: 2dbfd678ae31ec379ece016a0ceca20bGetting the same error on CachyOS
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed). Trace Id: 834de7a3ec95ed652aab31f6e3e273daSame on MacOS 27 0.0.45-nightly.20261001.2523
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).
Trace ID: b8838c4784811a0ba0520309158656e4
Reproduced today on macOS with T3 Code desktop 0.0.44. Enabling T3 Connect in Settings → Connections returns the toggle to off with
managed_endpoint_provisioning_failed.- Original trace:
f8f444f3bf4f07fc4ff5aacb9243fcc9 - Fresh retry trace:
994fe515cbc487d7cf90d24637988a3c
Local relay-client status and link-proof generation succeeded. No environment ID reset, credential deletion, or app restart was performed.
Please inspect the provisioning stage and underlying cause for these traces. I isolated the information loss in #14580 and opened #14581 to preserve the safe stage through the HTTP error and shared client message. The HTTP regression and compatibility tests pass locally. That PR is a diagnostics fix; it does not claim to repair this hosted provisioning incident.
- Original trace:
2 remaining items
Happening on Linux and Mac for me.
Also experiencing this on macOS with T3 Code (Alpha) 0.0.45.
Steps:
- Open “Set up T3 Connect.”
- Enable “Publish this environment” and “Publish agent activity.”
- Click Continue.
Error:
https://relay.t3.codes/v1/client/environment-links failed:
Relay cannot provision the managed endpoint
(managed_endpoint_provisioning_failed).Trace ID: 2c992b66718516f9754c1cd67fd5dc30
My existing manual connection to a separate Linux environment through Tailscale still works. The failure occurs when setting up T3 Connect.
Reproducing this on macOS with T3 Code
0.0.46-nightly.20261003.2610(8ed276c246b6), at approximately 2026-10-03 03:12 UTC.Enabling T3 Connect fails with:
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed). Trace ID: 25597a580e21282b94963cc39c9a38fcThe relay site loads from both devices, but provisioning still fails. I also received "Could not unlink relay environment" while trying to recover.
Same failure here, adding details for relay-operator lookup.
- T3 Code
0.0.46-preview.20261002.2598, Windows 11 x64 desktop app - Date: 2026-10-03 (local), trace ID:
4a4909123cc55310df6f2507597eb064 - Environment ID:
31fb48e3-5e62-4eae-8dbe-7628db3f4ddc(not reset) - Trigger: Settings → Connections → enable T3 Connect / publish this environment
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed). Trace ID: 4a4909123cc55310df6f2507597eb064Verified locally:
- Local server reachable on
http://127.0.0.1:3773. https://relay.t3.codes/healthreturns{"ok":true,"service":"relay"}.- Nothing matching this error string or trace ID is present in the local
server.trace.ndjson*/desktop.trace.ndjson*files.
Could a relay operator inspect
relay.managed_endpoint_provider.provisionfor this trace and report the failingstage/ underlying cause? Environment ID has not been reset.- T3 Code
Same failure on macOS, adding a trace for relay lookup.
- T3 Code
0.0.46-nightly.20261003.2610, macOS 26.5.1 arm64 - Date: 2026-10-03, shortly before 07:30 UTC
- Trace ID:
bb155179d81bd5b25ff746506edf7a4f - Environment ID:
a09ca184-7258-4c8b-93e3-bad690f73695(not reset) - First time enabling T3 Connect for this environment; sign-in to T3 Connect worked
- Trigger: Settings → Connections → enable T3 Connect
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed). Trace ID: bb155179d81bd5b25ff746506edf7a4f- T3 Code
Also reproducing on Linux (Ubuntu, systemd user service),
0.0.46-nightly.20261003.2623, cloudflared 2026.5.2, host on a home network (outbound only). This environment had a working managed tunnel before; it broke in two phases today.Environment ID:
75dd70e9-559d-4384-93fc-fbbdd3a67191(not reset)Phase 1: relay hands out a tunnel Cloudflare doesn't know (10:49–10:55 UTC)
At 10:53:15
registerManagedCloudTunnelRecoverysucceeded (T3 Connect managed tunnel recovery registered), but cloudflared kept getting:ERR Register tunnel error from server side error="Unauthorized: Tunnel not found" connIndex=0 event=0 ip=2606:4700:a8::3- tunnelId
dc1784d1-0e9a-4006-9b1f-95b14fc8a0cb, tunnelNamet3coderelay-managedendpoint-prod-2da265cb036e7a2a - Client-side gap:
isRejectedRelayClientTunnelOutput(apps/server/src/cloud/ManagedEndpointRuntime.ts) only matchesFailed to get tunnel/Record for tunnel not found/Invalid tunnel secret, soUnauthorized: Tunnel not foundnever triggers recovery. The connector just loops on warnings. Adding(?:Record for )?tunnel not foundto the pattern fixes the match.
Phase 2: unlink and relink both fail on the relay (10:55 UTC onward)
t3 connect unlink→ relay-environment-unlink HTTP 500, Ray IDa44b69e75988e862-FRA- After
t3 connect link+ service restart, everyreconcileDesiredLinkWithfails, alternating:- HTTP 504: Ray IDs
a44b6ac77a06af69-FRA,a44b6b07b802af69-FRA,a44b6d2d1d53d39e-FRA environment_link_unavailable/managed_endpoint_provisioning_failed: trace IDs45cf609151cac84a52cf5cb9330d5163,2c7987d32376a6c5fcb4ce044fec4cee,1f582f40bba8e51cf8ade43964fe45d0,a7f23d41c2ad5e0471fe9d4e06a84359,979023fc72fe5756f827dc3a9e9b95eb,f5c036e681855c5352804c725ab4c70c
- HTTP 504: Ray IDs
This matches the wedged-allocation theory: the relay's allocation pointed at a tunnel id Cloudflare had already deleted, and neither release (500) nor re-provision can get past it. Could you check the
stageonrelay.managed_endpoint_provider.provisionfor these traces?- tunnelId
Same failure on macOS (Apple Silicon), T3 Code
0.0.46-nightly.20261003.2623, 2026-10-03. Adding trace IDs and one detail that may help: the relay reaches the machine and gets HTTP 200 on health, yet still reports the endpoint as failed.Provisioning (
POST /v1/client/environment-links),managed_endpoint_provisioning_failed:9e1a5ac48bff5cf1537170f44835a5ff,d4010b04c99e09d07390e17fb27b04b2(12:11 UTC, unmodified app.asar)47fcc0fa0cf2452349a4cf14ceaf2774(13:33 UTC)
Health reported as failed while the environment answered 200:
- iOS shows "Managed endpoint health request failed. Trace ID:
be628adb6a84edf2a529ad462bcd2439". - The same trace ID is in the Mac's server trace:
POST /api/t3-connect/health→http.response.status_code: 200, spanenvironment.cloud.healthsucceeded. - At the same time cloudflared reported 4 ready connections (waw06, kbp02), 0 request errors, all tunnel responses 200.
Unlink also fails on the relay side:
t3 connect unlink→Relay internal error: upstream_unavailable, trace127eef4ed266101756e0ee17788f8461(13:55 UTC). Every app shutdown today also loggedreleaseManagedTunnelOnShutdownfailing withupstream_unavailable.The account now lists two "Yar MacBook Pro" server environments under T3 Connect, both "Relay offline"; removing them from iOS had no effect.
https://relay.t3.codes/healthreturns{"ok":true,"service":"relay"}, so the relay front is up while the environment-link backend seems unavailable.Also reproducing on Windows, 2026-10-03.
- T3 Code desktop 0.0.45, Windows <10/11, build ...>
- Settings → Connections → enable T3 Connect. The toggle returns to off with:
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).
- Trace ID:
c72409d4dfa1ae63ee75da07bfef7be7 - Local server is up on
127.0.0.1:3773. Network access: limited to this machine. WSL backend: off. Publish agent activity: off. - Tried: reinstalling the desktop app and signing out and back in. Same error on every attempt. I did not manually reset the environment ID.
Comment drafted with Claude (Anthropic) on my behalf.
Still reproducing on macOS on October 3, 2026. This is my third failed attempt to set up T3 Connect.
- T3 Code desktop:
0.0.46-nightly.20261003.2632 - Host: MacBook Pro, macOS. Exact OS version not captured.
- Latest copied trace ID:
7a1d1f107e0434267b652179e2e79b73 - Trigger: Settings → Connections → enable T3 Connect for the local environment.
The notification says “Could not update T3 Connect”. The toggle remains off, and the inline error reads:
https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).Expected: the managed endpoint is created and this environment becomes available to my other devices. Actual: setup fails repeatedly and T3 Connect access remains blocked.
The supplied trace ID and provisioning error were not found in the local desktop/server logs checked during this investigation. No HTTP response status or underlying provisioning stage was captured. No settings or credentials were changed during the investigation.
Could a relay operator inspect
relay.managed_endpoint_provider.provisionfor this trace and identify the failed stage and underlying cause?- T3 Code desktop:
Same issue here on Windows 11 after latest T3 Code updates: https://relay.t3.codes/v1/client/environment-links failed: Relay cannot provision the managed endpoint (managed_endpoint_provisioning_failed).
Trace ID: 533886ff68c712b9951bb3e5c9e8c303T3 Connect stopped working in the mobile app, and then I tried resetting it and now can't get it working.
Also reproducing on Windows, with a detail that may help: the environment drifted to publish-only before provisioning started failing.
- T3 Code desktop
0.0.46-nightly.20261003.2638, Windows 11 Pro build 26200 x64, cloudflared 2026.5.2 - Managed tunnel was working:
activateManagedTunnelsucceeded at 2026-10-03 21:40:16 UTC (tunnel namet3coderelay-managedendpoint-prod-901de12240737946) - 21:50:41 UTC: T3 Connect turned off while Publish agent activity was on.
CloudManagedEndpointRuntime.reconcileConfiglogged "Relay client stopped", so the link was relinked publish-only - Re-enabling:
environment.cloud.makeLinkProofsucceeds (21:50:45, 21:50:57, 21:51:31 UTC), thenPOST /v1/client/environment-linksreturnsmanaged_endpoint_provisioning_failed. Still failing after a server restart - Mobile (Android) in the meantime:
Relay rejected the environment connection request (endpoint_provider_not_managed), trace8b00e1ea098f341f1cbd3c382ea121ed. Matches the publish-only drift described in [Bug]: Connections settings cannot detect or repair a relay link that drifted to publish-only (toggle shows on, relink is a no-op, mobile gets endpoint_provider_not_managed) #11899 - Local server healthy on
127.0.0.1:3773;https://relay.t3.codes/healthreturns ok. Environment ID not reset, no unlink attempted
So once an environment leaves managed mode, re-provisioning hits this same failure. A user who toggles T3 Connect off and on loses mobile access until the relay is fixed.
Comment drafted with Claude Code (Claude Opus 5.5) via
t3 triage.- T3 Code desktop
this was not fixed btw
Reacted by Twilight and Ilya Kruchininthis was not fixed btw
Can't tell for Windows but I am no longer encountering this problem for MacOS.
I was just able to add the device on windows in the latest nightly on the device I've encountered the issue on
Before submitting
Area
T3 Connect hosted relay provisioning, triggered from the Windows desktop app.
Steps to reproduce
Expected behavior
T3 Connect provisions a managed endpoint and the environment becomes available to my mobile T3 app.
Actual behavior
The desktop app reports:
The local T3 server remains available on
127.0.0.1:3773. The relay health endpoint responds, but nocloudflaredconnector starts because provisioning fails before a tunnel token is returned.Impact
Mobile access to this Windows environment through T3 Connect is blocked. Local desktop use still works.
Environment
127.0.0.1:3773Trace IDs
fe743ccef63184b15eebc7f6d03dae1358a420de14b2a8e16b258082462bfac8b528e164721834faeeb4d9dff930d04ccf8e4071a1013229da78780a2cd32029Could the relay team inspect the failing stage and cause in
relay.managed_endpoint_provider.provisionfor these traces? The client only exposesmanaged_endpoint_provisioning_failed. I have not reset the environment ID or changed local credentials.