[Feature]: Mark WSL environments in their label, since WSL inherits the Windows host name

[inayayousfi]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

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:

$ cat /etc/hostname
internet-gyal-terminal

$ cmd.exe /c "echo %COMPUTERNAME%"
INTERNET-GYAL-T          # same name, truncated to the 15-char NetBIOS limit

The label resolver (apps/server/src/environment/ServerEnvironmentLabel.ts) walks a fallback chain, and on a stock WSL distro every friendly step misses:

1. /etc/machine-info → PRETTY_HOSTNAME. Not present on a default install.
2. hostnamectl --pretty. Returns empty even with systemd=true in /etc/wsl.conf.
3. 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 as environmentLabel (infra/relay/src/environments/EnvironmentLinks.ts).

Two collisions follow from this, not one:

• WSL vs its own Windows host.
• Two WSL distros on the same host, which also both inherit the same Windows name.

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_HOSTNAME into /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:

internet-gyal-terminal (WSL: archlinux)

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 the WSL_DISTRO_NAME env var. The repo already reads WSL_DISTRO_NAME in 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:

$ cat /proc/sys/kernel/osrelease
6.18.33.2-microsoft-standard-WSL2

$ systemd-run --user --quiet --wait --pipe /usr/bin/env | grep -i WSL
(nothing)

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 on osrelease containing microsoft, then read WSL_DISTRO_NAME for 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 resolveServerEnvironmentLabel only. No schema change, no protocol change, no client change, no migration. It is one branch in one function plus a case in ServerEnvironmentLabel.test.ts.

Alternatives considered

• Set PRETTY_HOSTNAME in /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.
• Change the WSL hostname via [network] hostname= in /etc/wsl.conf. Same objection, and it also changes the name for everything else on the machine, not just T3.
• A client-side "WSL" badge in the connection list instead of a label change. Does not mutate a value already persisted in saved connections. But it has to be built three times (web, mobile, desktop) and does nothing for anywhere else the raw label surfaces, e.g. thread rows and the preview title (apps/web/src/components/preview/previewUrlPresentation.ts).
• Add an in-app rename for environments. Solves this and more, but it is a much bigger feature with storage and sync questions. Worth doing on its own merits; not the cheap fix for this.

Risks or tradeoffs

• Do not append to a label the user chose. If PRETTY_HOSTNAME or scutil ComputerName produced the label, that is an explicit choice and must be left alone. The suffix belongs only on the HostProcessHostname fallback branch. Getting this backwards would override deliberate names.
• Already-paired clients keep the old label. Saved connections persist 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.
• Longer labels truncate. Sidebar and mobile thread rows already clip labels, so (WSL: archlinux) may be the part that gets cut — which is the part carrying the new information. A shorter form like · WSL may survive truncation better at the cost of losing the multi-distro disambiguation.
• osrelease matching 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 chain
• packages/shared/src/hostProcess.ts — HostProcessHostname default
• docs/user/background-service.md — the service install path where WSL_DISTRO_NAME is not present

Contribution

• I would be open to helping implement this.