Repository navigation
Manage T3 Connect environment names and registrations #13057
Description
Problem
Environment names come from their host machines, so two Macs can appear with the same name plus a numeric suffix. People need recognizable names such as Personal and Work, including for the environment they are currently using. Forgetting a saved connection locally leaves a stale T3 Connect registration discoverable, even when its original machine has been wiped.
Expected behavior
- Give each T3 Connect environment one account-wide name that appears on signed-in devices, including its own host. Make the current environment’s name easy to edit in Settings → Connections and let people restore its advertised machine name.
- Offer the same rename and restore actions for other saved or discovered environments, including in the T3 Connect account page and mobile profile.
- Let people deregister an environment from T3 Connect even when it is offline or not saved locally. Clearly distinguish that permanent action from removing a connection on one device.
- Refresh names without interrupting active connections or discarding a rename in progress.
Reacted by Robbie, Lucien Huber and EduardoGC21
Activity
[-]Allow saved environments to be renamed and deleted[/-][+]Manage T3 Connect environment names and registrations[/+]Raphi54 commentedon Oct 13, 2026
I have the same problem on Android (T3 server 0.0.45).
On the Environments screen, I see an old entry for my computer. The entry is red. It has the same name as the new entry for the same computer, and the new entry works. When I tap the old entry, nothing occurs. I cannot find a function to remove it on this screen.
The documentation says that you can remove an entry in Settings > T3 Connect > Deregister. The Environments screen does not tell you this.
Please do these two things:
gdowse-devbits commentedon Oct 15, 2026
Additional use case: one VM, multiple OS logins, one T3 Connect account
Supporting #13057 and the naming work in #13058 with a shared-host use case, rather than opening a duplicate request.
A single VM can host multiple OS logins, each running an independent T3 environment with its own T3 home, projects and provider credentials. One T3 Connect account intentionally manages all of them. Work and personal are common examples; separate client engagements, sandbox/test work and other contexts also apply.
All these environments currently inherit the same machine-derived name. Flexible names such as
sample-host-workandsample-host-personalwould improve the human user's context, make the active environment recognizable and reduce accidental cross-environment actions, without introducing the complexity of separate T3 Connect logins.This supports operational separation, not a new security boundary. OS users, permissions, homes, credentials and stable environment IDs provide the actual isolation. Renaming must not switch users, grant access or move credentials. The shared Connect account intentionally retains access to both environments.
Small native implementation option
The current
resolveServerEnvironmentLabelinapps/server/src/environment/ServerEnvironmentLabel.tsprefers the platform's friendly hostname, then the OS hostname, cwd basename and generic fallback. On Linux, the friendly name comes fromPRETTY_HOSTNAMEin/etc/machine-info, thenhostnamectl --pretty.A small complement to the account-wide naming work would be an optional advertised startup-name override, checked before the existing fallback chain:
T3CODE_ENVIRONMENT_NAMEis a proposed option, not an existing documented setting or a tested upstream patch. Each service could supply its own name without changing the host globally or patching installed releases. Unset, empty and whitespace-only values would preserve current behavior.An account-wide rename from the existing feature should take precedence over this advertised default. These resolver lines alone do not implement live account-wide renaming, persistence or refreshed client displays. That remains part of the existing request and linked work.
Acceptance checks
Validation Status
The current resolver was checked in the installed release and upstream source. A separate, disposable preload experiment passed six focused tests, including scope guards, unchanged unrelated file reads and a real subprocess that did not inherit the substituted hostname or preload options. Native T3 descriptor checks also passed for two sample names, reset to the native name and an unchanged environment ID.
Those checks validate only the local experiment. The native implementation sketch above has not been applied to upstream T3 Code. Real relay propagation, account-wide alias precedence, multiple-OS-user end-to-end behavior, all client surfaces and service-update compatibility remain acceptance work, not completed verification. No production service changes are proposed as evidence.
Drafted with Claude Opus 5.5 through Claude Code, invoked with
--effort high; prototype tests and review performed with GitHub Copilot.lcnbr commentedon Oct 20, 2026
This also affects desktop-managed SSH connections: I connect to the same IP using different SSH users, but both environments display the same machine name. Distinct aliases in
~/.ssh/configdon’t change the display names, making the environments hard to distinguish. Please support custom display names for SSH environments too.t3dotgg commentedon Oct 21, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Thanks for the idea. Feature requests and proposals belong in Ideas discussions, where others can find and vote on them and maintainers track direction, so we close them here (see CONTRIBUTING.md). If this still matters to you, please post it there and link this issue.
Brechard commentedon Oct 21, 2026
Reposted in Ideas as requested: Manage T3 Connect environment names and registrations #23118.
The discussion preserves the original proposal and links the additional reports from this issue.