Skip to content

[Bug]: T3 Connect environment is discoverable but relay connection is unauthorized (endpoint_provider_not_managed) #6568

Open
Open
[Bug]: T3 Connect environment is discoverable but relay connection is unauthorized (endpoint_provider_not_managed)#6568
Labels
bugSomething is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.

Description

@hichenym
hichenym
opened on Aug 14, 2026

Before submitting

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

Area

apps/web

Steps to reproduce

Summary

My Windows T3 Code environment is visible in the Android T3 Code app through T3 Connect, but it cannot be connected to.

The Android client reports that the relay connection is unauthorized because the endpoint provider is not managed. At the same time, the Windows desktop app cannot update or disable T3 Connect because it says that the environment is already linked to a different cloud account.

The environment is therefore stuck in an inconsistent state:

  • It remains registered and discoverable through T3 Connect.
  • Mobile clients cannot connect to it.
  • Desktop cannot configure relay access.
  • Desktop cannot turn off T3 Connect successfully.
  • Deregistering the environment does not resolve the problem.

Environment

  • Host name: DESKTOP-PCKC6UC
  • Host OS: Windows
  • Desktop client: T3 Code Nightly
  • Mobile client: T3 Code for Android
  • Time zone: Asia/Shanghai (UTC+8)
  • Desktop version: <paste exact version>
  • Android version: <paste exact version>
  • T3 Code installation method: <winget / GitHub release / other>

Android error

The Android app lists the environment under T3 Connect, but it remains offline and displays:

Connection failed. Reason: Relay environment connection is not authorized:
endpoint_provider_not_managed

### Expected behavior

Android trace ID:
1f504a9ff0c65281ddf366921d01751b
The Android Environments page shows:
No environments connected yet.
while DESKTOP-PCKC6UC is still listed below the T3 CONNECT section with a red status indicator.
Windows desktop error
In Settings > Connections, T3 Connect is enabled, but the desktop app shows:
Could not update T3 Connect

Could not configure environment relay access:
This environment is already linked to a different cloud account.
Unlink it before switching accounts.
The same message is also shown below the T3 Connect toggle:
Could not configure environment relay access:
This environment is already linked to a different cloud account.
Unlink it before switching accounts.
Trying to turn off T3 Connect also fails with an error instead of cleanly removing relay access.
T3 Connect account state
In Account > T3 Connect, the environment is still present:
DESKTOP-PCKC6UC
Linked Aug 14, 2026
Activity publishing only
The environment can be selected and the Deregister action is available, but deregistering it does not fix the relay/account conflict.
Expected behavior
One of the following should be possible:
The current account should be able to deregister the environment and remove all managed relay configuration.
The environment should be unlinked from the previous cloud account and linked to the current account.
If the environment cannot be recovered automatically, the UI should clearly explain how to remove the stale relay ownership.
After recovery, the Android app should be able to connect to DESKTOP-PCKC6UC through T3 Connect.
Actual behavior
The environment is visible but unusable:
Android discovers DESKTOP-PCKC6UC through T3 Connect.
Android connection fails with endpoint_provider_not_managed.
Windows cannot configure relay access because the environment is reported as linked to a different cloud account.
Disabling T3 Connect on Windows fails.
Deregistering the environment does not clear the state.
The environment remains registered as Activity publishing only.
Steps to reproduce
The original account transition is not fully clear, but the current broken state can be reproduced consistently:
Sign in to T3 Code Desktop on Windows with the current T3 Connect account.

Open Settings > Connections.

Enable T3 Connect, or attempt to update its configuration.

Observe:
This environment is already linked to a different cloud account.

Attempt to disable T3 Connect.

Observe that the operation fails instead of removing relay access.

Open Account > T3 Connect and attempt to deregister DESKTOP-PCKC6UC.

The stale environment state remains unresolved.

On Android, sign in with the same current T3 Connect account.

Open Environments.

Observe that DESKTOP-PCKC6UC is discoverable under T3 Connect but connection fails with:

Relay environment connection is not authorized:
endpoint_provider_not_managed
Attempted recovery
I have already tried:
Restarting T3 Code Desktop on Windows.
Reopening/restarting the Android app.
Turning T3 Connect off and on again.
Refreshing the T3 Connect environment list.
Attempting to deregister the environment from Account > T3 Connect.
Attempting to reconnect from Android.
Updating/reconfiguring T3 Connect from Settings > Connections.
None of these actions removed the stale relay/account state.

Related issue
This appears related to the relay-unlink / invalid-environment-credential failure mode reported in:
#5712 — T3 Connect: /oauth/token returns EnvironmentAuthInvalidError after relinking environment
However, this issue has a different current Android-side failure:
endpoint_provider_not_managed
This may indicate that the relay environment record still exists, but its managed endpoint provider configuration has been removed or is no longer associated with the currently registered environment.

Request
Could you please investigate the inconsistent T3 Connect state for this environment and advise on recovery?
I need the stale relay ownership and/or unmanaged endpoint configuration for DESKTOP-PCKC6UC to be cleared so that it can either:
be cleanly deregistered, or
be linked to my current T3 Connect account and used from Android again.
If server-side cleanup is required, please let me know which additional non-sensitive identifiers or logs are needed.

Attachments
I attached screenshots showing:
Windows: Could not update T3 Connect and the different cloud account error.
Android: endpoint_provider_not_managed with trace ID 1f504a9ff0c65281ddf366921d01751b.
Desktop Account > T3 Connect: DESKTOP-PCKC6UC registered as Activity publishing only.

### Actual behavior

<img width="1041" height="676" alt="Image" src="https://github.com/user-attachments/assets/c4effa09-cd31-4674-a167-b7ced73d6aa1" />

<img width="1080" height="2340" alt="Image" src="https://github.com/user-attachments/assets/7ef78f76-bbd6-4233-bf10-07cf13a7d3af" />

<img width="1038" height="664" alt="Image" src="https://github.com/user-attachments/assets/3b8538f9-d718-431a-ac62-d566468b20ba" />

### Impact

Blocks work completely

### Version or commit

_No response_

### Environment

_No response_

### Logs or stack traces

```shell

Screenshots, recordings, or supporting files

No response

Workaround

No response

Activity

  1. hichenym
    added
    bugSomething is broken or behaving incorrectly.
    needs-triageIssue needs maintainer review and initial categorization.
    on Aug 14, 2026

  2. Destreyf commented on Aug 14, 2026

    @Destreyf
    Destreyf
    on Aug 14, 2026

    I am having a similar issue with t3 connect right now, I run a remote/server instance and connect via mobile & desktop to it, randomly lost connection and was getting an environment_link_not_found error so I stopped my server, logged out the tunnel, logged it back in, and then it started giving me endpoint_provider_not_managed after starting t3code back up.

  3. ElliotDrel commented on Sep 15, 2026

    @ElliotDrel
    ElliotDrel
    on Sep 15, 2026

    Hit the same endpoint_provider_not_managed on Windows desktop 0.0.40 + iOS and traced it through the code. Root cause and a working recovery below, in case it helps here.

    What the error means

    The relay refuses connect whenever its stored link for the environment has endpoint.providerKind !== "cloudflare_tunnel" (infra/relay/src/environments/EnvironmentConnector.ts, resolveManagedEndpoint). The only other kind the desktop sends is manual, which is the "publish only" link. Your screenshot showing the environment as "Activity publishing only" under Account > T3 Connect is that exact state: the relay thinks there is no managed tunnel, so it will not route a connection to it, while the environment stays discoverable and health checks keep passing.

    How it gets there

    The desktop Settings > Connections toggles: with Publish agent activity on, turning T3 Connect off does not unlink. It relinks in publish-only mode (useCloudLinkController.ts, mode: desired.managedTunnel ? "managed" : "publish_only"). And the relink flow commits the relay record before it persists the local relay config (applyCloudRelayConfig in apps/server/src/cloud/http.ts writes six secrets one at a time with no rollback). In my case the local write failed after the first file, so the relay had manual while the desktop still believed it was managed and cloudflared kept the old tunnel up. Turning the toggle on again then does nothing, because the UI only relinks when its local managedTunnelActive differs from the desired state. Filed as #11898 (server, non-atomic apply) and #11899 (UI cannot detect or repair the drift).

    Recovery that worked

    Settings > Connections: turn Publish agent activity off, then T3 Connect off (only that combination actually unlinks), then T3 Connect on, then publishing back on. That rewrote the relay record as cloudflare_tunnel and the phone connected on the next try.

    @hichenym your "already linked to a different cloud account" error is an extra layer on top of this: that check is validateLinkedCloudUser comparing the relay's cloudUserId against ~/.t3/userdata/secrets/cloud-linked-user-id.bin on the desktop. If those differ, the toggle sequence above will fail at the "on" step. Deleting that one file (with T3 Code closed) and then running the sequence should let the current account take the link. @Destreyf the tunnel logout/login path lands in the same relay state, so the same sequence should apply.

  4. Destreyf commented on Sep 15, 2026

    @Destreyf
    Destreyf
    on Sep 15, 2026

    @ElliotDrel mine resolved itself at some point, not sure when, but t3 connect works for me now without any changes on my end aside from removing my workaround SSH connections, I am on nightly though.

  5. ElliotDrel commented on Sep 15, 2026

    @ElliotDrel
    ElliotDrel
    on Sep 15, 2026

    Settings > Connections: turn Publish agent activity off, then T3 Connect off (only that combination actually unlinks), then T3 Connect on, then publishing back on. That rewrote the relay record as cloudflare_tunnel and the phone connected on the next try.

    worked for me on stable too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething is broken or behaving incorrectly.needs-triageIssue needs maintainer review and initial categorization.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions