Repository navigation
Description
What happened
Settings → Sharing & access → Authorized clients shows two entries named “T3 Connect connect.” Both have the same visible Desktop, macOS, Electron, loopback address, and 16-scope metadata. One has a connected status dot and the other does not.
The repeated word looks accidental, and the identical names make it hard to identify which client each Revoke button affects. A clear name should identify the client or device, with a distinguishing detail when multiple sessions share the same metadata.
Diagnosis
The cloud credential mint path hardcodes label: "T3 Connect connect" in CloudLink.ts.
AuthorizedClientsSettings.tsx displays the stored client label as the row title. This explains the naming, but does not establish why two sessions exist. No duplicate-session or authorization failure is claimed.
The same label and rendering logic remain at checked main cb9629e6891ef0745772b69f09c9acd0c6a74f7e.
Steps to reproduce
- With a desktop client connected to an environment through T3 Connect, open that environment's Settings → Sharing & access.
- Expand Authorized clients.
- Inspect the names of T3 Connect sessions. The cloud mint path assigns the repeated label above.
The supplied screenshots show two such entries. The sequence that created both was not reproduced during triage.
Version
0.1.6-nightly.20261030.3940, commit ae521d1d796c4e21abb49e44d27c23332d1898b9. This is the screenshot build and the verified installed desktop/server version.
Environment
Official T3 Code Nightly desktop on macOS, Darwin 27.0.0, arm64. Node v24.22.1.
Evidence
User-provided screenshot of Authorized clients, plus the pinned source links above. Investigation was limited to the displayed naming and relevant source. No runtime session-creation cause was established.
Related issues
- #27688 covers incorrect link-dialog navigation instructions, separately.
- #7910 reports duplicate Android authorization flows. This report concerns desktop client naming and does not claim the same cause.
- #13054 concerns editing client labels after creation. This report concerns the generated default label.
Bounded open and closed issue searches found these related reports, without establishing a direct duplicate for the naming problem.
Fix applied or workaround
None. No clients were revoked or renamed. A clearer default name would require an upstream change.
Filed by
Codex, gpt-6.1-sol, via T3 Code triage.
Activity