[Feature]: Mark WSL environments in their label, since WSL inherits the Windows host name #6826
inayayousfi
started this conversation in
Ideas
Replies: 1 comment
|
Written by inayayousfi, typed by gpt-5.6-sol running in OpenCode. A broader manual naming path is now ready for review in PR #7267. It lets users assign a server-owned environment name from web, desktop, or mobile, then propagates that name to connected clients and T3 Connect. That handles WSL versus Windows collisions, multiple WSL distributions, and the same class of collision on other platforms. PR #7267 does not detect WSL or add a distro suffix automatically. PR #6053 remains the narrower zero-configuration fix, and I hope it can land alongside the manual rename support. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Before submitting
Area
apps/server
Problem or use case
A WSL environment and the Windows machine hosting it show up under the same name, so the connection list has two entries I cannot tell apart.
This is because WSL2 defaults its Linux hostname to the Windows computer name. On my machine:
The label resolver (
apps/server/src/environment/ServerEnvironmentLabel.ts) walks a fallback chain, and on a stock WSL distro every friendly step misses:/etc/machine-info→PRETTY_HOSTNAME. Not present on a default install.hostnamectl --pretty. Returns empty even withsystemd=truein/etc/wsl.conf.HostProcessHostname, i.e.NodeOS.hostname()(packages/shared/src/hostProcess.ts). This is what actually wins, and it is the mirrored Windows name.That label goes straight onto the
ExecutionEnvironmentDescriptor(apps/server/src/environment/ServerEnvironment.ts:127-134) and is what every client renders, plus what the relay stores asenvironmentLabel(infra/relay/src/environments/EnvironmentLinks.ts).Two collisions follow from this, not one:
I could not find a rename affordance in Connections settings, so there is no in-app way out. The only fixes are outside the app: change the Linux hostname, or write
PRETTY_HOSTNAMEinto/etc/machine-info.Proposed solution
When the server detects it is running under WSL and the label came from the plain hostname fallback, disambiguate the label with the WSL distro:
The distro name is what makes this work for the multi-distro case too, not just for WSL vs Windows.
Detect via
/proc/sys/kernel/osrelease, not theWSL_DISTRO_NAMEenv var. The repo already readsWSL_DISTRO_NAMEin two places (apps/server/src/telemetry/AnalyticsService.ts,apps/server/src/process/externalLauncher.ts), but that variable is injected into interactive WSL sessions and is not inherited by systemd units. Verified on my machine:So an env-var-only check would silently do nothing for anyone running the server through the background service — which is exactly the T3 Connect setup described in
docs/user/background-service.md. Suggested shape: gate onosreleasecontainingmicrosoft, then readWSL_DISTRO_NAMEfor the distro string and fall back to a bare(WSL)suffix when it is absent.Why this matters
Anyone on Windows using the WSL backend hits this on the first device they add, and it gets worse as they add more. Picking the wrong environment is not a harmless mistake here: it routes a thread at a different filesystem with different tooling. Naming the environment correctly at registration is cheap and removes a whole class of "why is my project not here" confusion.
Smallest useful scope
Suffix the label inside
resolveServerEnvironmentLabelonly. No schema change, no protocol change, no client change, no migration. It is one branch in one function plus a case inServerEnvironmentLabel.test.ts.Alternatives considered
PRETTY_HOSTNAMEin/etc/machine-info. Works today and the resolver already honors it. But it asks every WSL user to hand-edit a system file to get a distinguishable name, and it silently does nothing until they discover it.[network] hostname=in/etc/wsl.conf. Same objection, and it also changes the name for everything else on the machine, not just T3.apps/web/src/components/preview/previewUrlPresentation.ts).Risks or tradeoffs
PRETTY_HOSTNAMEorscutil ComputerNameproduced the label, that is an explicit choice and must be left alone. The suffix belongs only on theHostProcessHostnamefallback branch. Getting this backwards would override deliberate names.environmentLabel(apps/mobile/src/connection/migration.ts), so existing devices show the old name until they re-read the descriptor. New pairings are correct immediately. Acceptable, but it means the fix does not visibly land for current users on day one.(WSL: archlinux)may be the part that gets cut — which is the part carrying the new information. A shorter form like· WSLmay survive truncation better at the cost of losing the multi-distro disambiguation.osreleasematching is a substring check on a kernel string. It is stable in practice across WSL1 and WSL2, but it is a heuristic, not an API.Examples or references
apps/server/src/environment/ServerEnvironmentLabel.ts— the fallback chainpackages/shared/src/hostProcess.ts—HostProcessHostnamedefaultdocs/user/background-service.md— the service install path whereWSL_DISTRO_NAMEis not presentContribution
All reactions