Repository navigation
[Bug]: Saved T3 Connect environments keep their original label after the host's machine name changes #15683
Description
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
(The bug is in packages/client-runtime, which all clients share — web, desktop and mobile — plus infra/relay.)
Steps to reproduce
- Link a Mac whose
ComputerNameisJL-Mac-Studio-M3-Ultrato T3 Connect, then add it as an environment on a client. - Move to a new Mac with Migration Assistant. It copies
~/.t3/userdata/environment-id, so theenvironmentIdstays the same. The new machine is namedJL-Mac-Studio-M5-Ultra. - Start T3 Code on the new Mac. In the client from step 1, open Settings → Connections → Environments and check the environment chip in the composer.
Expected behavior
The environment is shown as JL-Mac-Studio-M5-Ultra. That is the name the server reports in its descriptor, and the name a fresh T3 Connect discovery list shows.
Actual behavior
Settings → Environments and the composer environment chip still show JL-Mac-Studio-M3-Ultra, next to "T3 Connect · Connected". A T3 Connect environment that has not been saved on the client yet shows the new name.
The host itself is fine. scutil --get ComputerName, scutil --get LocalHostName, scutil --get HostName and hostname all return JL-Mac-Studio-M5-Ultra. The server reads its label from scutil --get ComputerName every time it starts (apps/server/src/environment/ServerEnvironmentLabel.ts).
Impact
Cosmetic issue
Version or commit
Desktop 0.0.46-nightly.20261004.2648; main @ 4ee6bfd
Environment
macOS 27.0.1, Apple M5 Ultra, T3 Code (Nightly) desktop, T3 Connect
Logs or stack traces
No response
Screenshots, recordings, or supporting files
Workaround
From reading the code (not tested): remove the saved environment and add it again from T3 Connect. The label is copied from discovery again when the environment is added.
Root cause
Two copies of the label are stored, and neither one is ever updated:
- The client's saved target keeps the label it had when it was added. When an environment is added,
RelayConnectionTarget.labelis copied from the discovery record. This happens inapps/web/src/components/cloud/CloudEnvironmentConnectList.tsx,apps/mobile/src/features/connection/useConnectionController.ts, and the legacy migration inapps/desktop/src/app/DesktopConnectionCatalogStore.ts. Settings and the composer chip display that catalog entry. On every connect,ConnectionResolver.authorizeinpackages/client-runtime/src/connection/resolver.tsfetches the liveExecutionEnvironmentDescriptor, but it only comparesenvironmentIdand discardsdescriptor.label. Discovery results are never written back into saved targets either. Bearer and SSH saved environments storelabelthe same way, so they probably have the same problem. - The relay link row is only updated on an explicit re-link.
relay_environment_links.environment_labelis written only byEnvironmentLinks.upsertininfra/relay/src/environments/EnvironmentLinks.ts. That runs when the environment is linked through desktop T3 Connect linking ort3 connect. A server boot does not refresh it, so discovery also shows the old name if the host is renamed without re-linking.
Suggested fix
- Smallest fix: once
authorizesucceeds, comparedescriptor.labelwithtarget.label. If they differ, write the new label to the catalog entry. The descriptor is already fetched on every connect, so this adds no request, and it fixes relay, bearer and SSH environments together. - Optional: when relay discovery refreshes, sync the labels of saved relay targets so that offline environments also get the new name.
- Relay: refresh
environment_labelwhen the server re-establishes its managed endpoint. - If Manage T3 Connect environment names and registrations #13057 adds custom names that apply across the account, the rule should be "follow the advertised machine name unless the user renamed it". That keeps it to one label instead of adding a second label field.
Related
- Manage T3 Connect environment names and registrations #13057 (Manage T3 Connect environment names and registrations). That issue requests custom naming and asks to "refresh names without interrupting active connections". This issue is the concrete bug behind the stale names.
Activity
Screenshots for stale T3 Connect environment label issue (pingdotgg#1…
jlipworth commentedon Oct 4, 2026
Screenshots, taken on the client after the host was renamed to
JL-Mac-Studio-M5-Ultra:Composer environment chip: still shows the old name
Settings → Environments: old name, connected through T3 Connect
juliusmarminge commentedon Oct 4, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks for the thorough report, @jlipworth. The Migration Assistant detail and the root-cause notes lined up well with the code.
What I found
Confirmed on
mainat4ee6bfd50e. This is separate from #13057.entry.target.label). That label is copied once, when the environment is added: inCloudEnvironmentConnectList, in the mobile connect path, and in the desktop catalog migration.ConnectionResolver.authorizeloads the liveExecutionEnvironmentDescriptoron every connect and checksenvironmentId, then discardsdescriptor.label. Relay auth and discovery health also read the descriptor, but neither writes the name back to the saved target.EnvironmentRegistry.registerreplacestarget.label, which matches the workaround you suggested.resolveServerEnvironmentLabelrunsscutil --get ComputerNameonce per process, so a restart is what picks up the new name.environment_labelis written only byEnvironmentLinks.upsert. Startup calls that only whenmanagedTunnelStartupActionreturnsreconcile_link, so an already-linked host that comes backreadykeeps its old relay label. Your unsaved T3 Connect row showing the new name suggests the link was refreshed during the migration, which points to the saved catalog as the stale copy here.labelthe same way, so they're probably affected too. The local primary and desktop-local backends already rebuild from the descriptor.Likely fix area
authorize, update the catalog entry's label wheneverdescriptor.labeldiffers. That needs no extra request and covers relay, bearer, and SSH targets alike.environment_labelfor already-linked hosts on startup.A maintainer will decide on the fix direction.
timharris707 commentedon Oct 18, 2026
Claude Opus 5.5 via Claude Code, responding on behalf of Tim Harris:
Adding a data point from #21270, which was closed as a duplicate of this issue. On 0.1.0, running
t3 connect linkagain, and event3 connect unlinkfollowed byt3 connect link, did not refresh the relay'senvironment_label. The old name kept showing in a fresh discovery list and under T3 Account > T3 Connect > Registered servers, not only in saved entries.So a fix that only updates the client's saved label after
authorizewould not cover this case. The relay seems to keep the label from the first link for as long as the environment identity exists.#21270 also describes a separate problem this issue doesn't cover: after creating a new environment identity, every client got
environment_link_not_founduntil a fullt3 connect logoutand sign-in. Happy to file that on its own if it's useful.juliusmarminge commentedon Oct 22, 2026
Checked current main at b5a226e49c in an isolated Linux worktree. Ran
vp run dev, opened the web client, then Settings → Connections → Add environment. This development build offers only host/code pairing, with no T3 Connect discovery, so I could not run the saved-relay rename sequence. The real-data snapshot also failed migration, so this attempt used empty state. This is not a successful reproduction or evidence that the bug is fixed.Can you confirm on the latest nightly whether restarting the renamed host leaves (1) its saved environment label and (2) its fresh T3 Connect discovery label stale? Include the client and host versions. The later comment reports both labels staying stale, whereas the original report says fresh discovery has the new name.
YasserDRIF commentedon Oct 26, 2026
Another repro on the current release, for the "saved label stale after host restart" case.
Host: macOS (arm64), T3 Code server
0.1.2Steps
Yasser's MacBook Pro (2)toYasser - Suture(scutil --setforComputerName,LocalHostName, andHostName).Result
label: "Yasser - Suture"with the sameenvironmentIdas before.Yasser's MacBook Pro (2)for this environment after a full restart of both the host and the app.So (1) the saved environment label on the mobile client stays stale even though the restarted host advertises the new name. I haven't checked (2), the fresh discovery list, yet. I'll add the mobile app version and the discovery result when I have them.
Hormold commentedon Nov 6, 2026
+1, hit this today on 0.1.8 nightly. got 2 macs paired and they show up as "MacBook Pro" and "MacBook Pro 4" lol. renamed the second one in macos, its server already returns "Old Mac" from /.well-known/t3/environment but the desktop app still shows MacBook Pro 4
only way i found to fix it is remove from this device -> new pairing code -> pair again. thats too much for a name change
can you just add Rename to the ... menu in Settings > Connections? local name only, nothing on the server. and if i didnt set a custom name just take the label from the server on reconnect, that would fix this issue too
jacobcorbett commentedon Nov 6, 2026
Additional reproduction on stable 0.1.7 (6 November 2026): native Windows 11 host, macOS desktop client, T3 Connect.
After renaming the Windows machine, the same environment identity advertised its new name through
/.well-known/t3/environment. Both the saved client environment row and the fresh T3 Connect discovery row continued to show the old name. The peer-linked environments section already showed the new name.What we checked:
t3 connect unlink,t3 connect link --headless, and restarting the host caused startup link reconciliation. The macOS discovery/saved row then showed the new name.The unlink operation initially reported
upstream_unavailable; subsequent startup reconciliation succeeded. The descriptor retained the same environment ID. We did not create a new identity.The relink also caused a separate client-side outage matching #27250: the tunnel was connected, but the client's recursive DNS chain cached NXDOMAIN for its hostname while a public resolver returned valid records. HTTPS to the exact environment descriptor endpoint succeeded when resolved to the public address. A domain-specific DNS resolver override restored normal client connectivity. This reinforces the value of refreshing the advertised name without unlinking/relinking.
PR #27542 addresses saved client labels; this reproduction also needs the relay discovery label refreshed for an already-linked host. No claim of reproduction on the latest nightly or current main.