[Bug]: T3 Connect environment never appears in mobile app despite provisioned link and registered relay tunnel (Linux aarch64)

[valentindimitrov]

Before submitting

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

Closest existing issues are a different failure mode — in #7139, #6568 and #5332 the
environment is discoverable and the connection fails. Here the environment never appears
in the mobile app at all, despite the server reporting the link as fully provisioned.

Area

apps/web (T3 Connect / relay discovery)

Steps to reproduce

1. Install t3 0.0.33 on Linux aarch64, run it via the managed background service
   (t3 service install → t3code.service, systemd user unit, launcher-managed).
   Server binds loopback only: 127.0.0.1:3773.
2. t3 connect login / t3 connect link, completing the browser OAuth flow.
3. systemctl --user restart t3code.service to provision the link.
4. Confirm server-side state is healthy (see below).
5. Open the T3 Code mobile app, signed in with the same account used in step 2.

Expected behavior

The environment (gx10) appears in the mobile app's environment list, reachable over
the relay.

Actual behavior

The environment never appears in the mobile app. Not "appears but won't connect" — it is
never listed at all.

Server-side everything reports healthy:

T3 Connect
  Exposure: enabled
  Authorization: stored credential
  Environment link: provisioned
  Relay: https://relay.t3.codes
  Publish agent activity: disabled
  Relay client: available via managed install
    Path: ~/.t3/tools/cloudflared/2026.5.2/linux-arm64/cloudflared
    Version: 2026.5.2

Settings → Connections in the local web UI also shows T3 Connect toggled on.

Verified there is exactly one t3 server process and one relay client — both inside
the t3code.service cgroup — and that server-runtime.json matches the running pid.
(An earlier duplicate-instance situation was eliminated first; see the CLI note below.)

Additionally, neither Publish agent activity nor the Administrative access control
can be enabled from the local UI, so the tunnel-independent activity channel cannot be used
as a fallback or as a way to isolate the fault.

Impact

Blocks remote access entirely — mobile clients cannot reach the environment.

Version or commit

t3 0.0.33 (server), cloudflared 2026.5.2

Environment

Linux aarch64 (Ubuntu 24.04 / NVIDIA DGX OS 7.5, GB10), Node 22.23.2, systemd user service,
server bound to 127.0.0.1:3773.

Logs or stack traces

Link reconciles and the tunnel registers across four Cloudflare edges on every start:

[00:17:52] INFO: Relay client tunnel connection registered
    tunnelName: 't3coderelay-managedendpoint-prod-<redacted>'
    output: 'INF Registered tunnel connection connIndex=0 ... location=cdg15 protocol=quic'
[00:17:52] INFO: Relay client tunnel connection registered   (connIndex=1, cdg09)
[00:17:54] INFO: Relay client tunnel connection registered   (connIndex=2, cdg09)
[00:17:55] INFO: Relay client tunnel connection registered   (connIndex=3, cdg08)
[...]      INFO: T3 Connect desired link reconciled on startup

No errors. The only warning is unrelated to transport:

WRN ICMP proxy feature is disabled error="cannot create ICMPv4 proxy:
Group ID 1000 is not between ping group 1 to 0 nor ICMPv6 proxy: socket: permission denied"

Workaround

None found. Sign-out/sign-in, re-linking, and full service restarts do not change the
outcome. Local access works normally via t3 pair and the loopback URL.

---

Two CLI issues encountered while debugging this

Both cost significant debugging time and may be worth splitting out — happy to file
separately if preferred.

1. Unrecognised subcommands silently start a server. A typo — t3 pait instead of
t3 pair — did not error. It started a second server, which could not bind 3773 (held by
the service), so it took a random loopback port, overwrote server-runtime.json, and
started a second cloudflared registering against the same tunnel ID. On exit it deleted
the discovery record, leaving the healthy service running but invisible to t3 pair
("no server found"). Suggest erroring on unknown subcommands instead of falling through.

2. t3 doctor starts a server. Expected a read-only diagnostic; it bound
127.0.0.1:39347, printed a pairing URL, and spawned another relay client against the same
tunnel ID — reproducing the duplicate-tunnel state above.

Together these make it easy to end up with competing servers and duplicate tunnels without
realising it, which materially complicates diagnosing any Connect problem.