`entire login` opens a Linux browser instead of the Windows default browser under WSL

What happened?

On WSL2 with WSLg and a Linux browser installed (e.g. Chrome via apt), entire login opens the sign-in page in the Linux browser — a fresh profile with no Google/GitHub/Entra sessions — instead of the Windows default browser where the user is already signed in. Every other CLI on the box (gh auth login, wslview-aware tools) opens the Windows browser.

Root cause: on Linux, openBrowser hardcodes xdg-open. Under WSL, xdg-open resolves the x-scheme-handler/https MIME handler — which the mere installation of a Linux browser claims — and that wins over both $BROWSER and xdg-settings get default-web-browser. Verified on an affected machine:

$ echo $BROWSER
wslview
$ xdg-settings get default-web-browser
wslview.desktop
$ xdg-mime query default x-scheme-handler/https
com.google.Chrome.desktop        # ← what xdg-open actually uses

There's a second-order issue once the Windows browser is used: the default loopback (authorization-code) flow binds 127.0.0.1 inside WSL, so the redirect from the Windows browser depends on WSL2 localhostForwarding. That usually works, but fails under mirrored-networking/VPN setups — the same "browser can't reach this machine's 127.0.0.1" shape that #1403 already handles for SSH by falling back to the device flow.

Steps to reproduce

1. WSL2 (Ubuntu) with WSLg and a Linux browser installed (apt install google-chrome-stable)
2. Windows browser signed in to your IdP; Linux browser fresh
3. entire login, press Enter at the prompt
4. Linux Chrome opens with no sessions instead of the Windows browser

Proposed fix

Detect WSL via /proc/version (env vars like WSL_DISTRO_NAME can be stripped in hook/service contexts) and open the Windows browser directly — wslview when present (ships with wslu, preinstalled on Ubuntu WSL), else cmd.exe /c start. For the redirect-can't-reach-WSL case, extend the #1403 loginFlowFacts pattern with a wsl fact and race the loopback wait against an Enter keypress that falls back to the device flow. PR incoming.

Entire CLI version

Entire CLI 0.8.42

OS and architecture

Ubuntu (WSL2) x86_64, Windows 11 host

Agent

n/a (CLI auth flow)

Start at the openBrowser implementation and the loginFlowFacts pattern referenced in the issue, then reproduce the flow on WSL2 with a Linux browser installed. Verify that login opens the Windows browser and that an unreachable loopback redirect can fall back to the device flow, using the existing #1403 behavior as context.