WSL remote: a maintained open-source extension (n2ns.wsl-remote) — whitelist request, and an offer to take over the role of open-remote-wsl #3074

Context

• Make the WSL remote extension work in VS Codium #1265 (open since 2022) tracks WSL remote development in VSCodium. In that thread @daiyam wrote: "The best would be to have an open-source equivalent of that extension."
• Today VSCodium points users at jeanp413.open-remote-wsl: docs/extensions-compatibility.md lists it under Remote Development, dev/update_api.sh adds it to extensionEnabledApiProposals, and patches/windows/00-remote-use-open-ext.patch makes codium inside WSL default to it (VSCODE_WSL_EXTENSION_ID).
• That extension looks unmaintained. As of 2026-10-18 its last commit and last merge date from 2025-04-06 (v0.0.5); three pull requests are open without a reply (Rename macOS app to VSCodium.app #11 from 2024-10 about broken/raced server downloads, Better oss icon #25 from 2026-04 adding the codium-from-WSL scripts, Add Windows build configuration (#8) #29 from 2026-09 fixing shell injection in the setup script), and 19 issues are open, among them Rename app to VSCodium #12 (download race), Undo telemetry before build #27 (localhostForwarding=false), Latest Release Missing OSX #3 (Alpine) and Setup RPM/Deb packages repositories #5 (codium from inside WSL).

What we did

We wrote a new extension from scratch rather than patching a 31 KB bundle: WSL Remote, id n2ns.wsl-remote, MIT, TypeScript with tests and CI. Repository: https://github.com/n2ns/wsl-remote (Open VSX publication under the n2ns namespace follows once the id question below is settled, so early users do not have to reinstall).

Feature parity with open-remote-wsl (same commands, Remote Explorer view with recent folders, status bar entries, label formatter, download URL setting), plus the points its open issues and PRs ask for:

• server-env-setup hook: ~/.vscodium-server/server-env-setup is sourced before the server starts, exactly like Microsoft's ~/.vscode-server/server-env-setup. open-remote-wsl starts the server from a non-login bash -c and sources nothing, so there was no way to put a variable into the remote extension host's environment on VSCodium.
• No shell interpolation: wsl.exe is always spawned with an argument array; everything the Linux-side script needs arrives through environment variables (WSLENV); distribution names are validated (Add Windows build configuration (#8) #29 / Remove "VS" from name? #28 there).
• Safe server installation: mkdir lock across windows, published .sha256 verified, tar -tzf check, extraction into a temporary directory and atomic move, corrupt downloads removed with a clear message (Rename macOS app to VSCodium.app #11, Rename app to VSCodium #12, If vscode folder exists, fetch updates not invoke clone #19 there).
• Server start: --start-server with a connection token file; the launcher runs in its own process group and the whole group is stopped when the window closes (open-remote-wsl's kill of the launcher alone leaves node server-main.js and the pty host behind); the usual <data dir>/.<commit>.pid is still written for tools that rely on it.
• localhostForwarding=false / NAT without forwarding: falls back to the distribution address with a local port relay (Undo telemetry before build #27 there).
• codium <dir> from inside WSL: scripts/wslCode.sh implements the launcher contract your Windows patch already expects, so VSCODE_WSL_EXTENSION_ID=n2ns.wsl-remote codium . works today (Setup RPM/Deb packages repositories #5, PR Better oss icon #25 there).
• Alpine: detected, libstdc++ checked, vscodium-reh-alpine-* downloaded (Latest Release Missing OSX #3 there; not yet tested on a real Alpine install).
• Proposed API without a product.json entry: when resolvers is not enabled for the id, the extension offers to add itself to enable-proposed-api in argv.json (JSONC edit, backup kept, restart prompt). A whitelist entry removes that extra step; it is not a prerequisite.
• CI runs scripts/server-setup.sh against the latest VSCodium release every week (download, verify, start, stop), so a changed REH layout or URL shows up before users hit it.

Verified so far on Windows 11 / WSL 2.6.3 (mirrored networking) / Ubuntu 26.04 / VSCodium 1.135.06055 with real workloads (plan-swap, Codex, Claude Code extensions in the remote host). Not yet covered: Alpine and NixOS on real installs, Windows 10.

What we are asking

1. Add n2ns.wsl-remote to extensionEnabledApiProposals in dev/update_api.sh, with the same proposals as jeanp413.open-remote-wsl: ["resolvers", "contribRemoteHelp", "contribViewsRemote"].
2. Once it is on Open VSX, list it in docs/extensions-compatibility.md next to (or instead of) Open Remote - WSL.
3. If you would prefer the extension to live under the VSCodium organization, we are open to transferring the repository and the Open VSX namespace; we would keep maintaining it either way.

Happy to answer questions here or in the repository. cc @daiyam