How to install WSL2 (and what it actually is)
One admin PowerShell command installs a real Linux kernel in a lightweight VM, Ubuntu included. The install steps, the BIOS trap, the systemd detail, and what it means for agents.
Open PowerShell as administrator, run wsl --install, and restart. Per Microsoft’s docs, that one command enables the required Windows features and installs Ubuntu, set to WSL 2 by default. You need Windows 10 version 2004+ (build 19041+) or Windows 11, and virtualization enabled in BIOS. After the restart, Ubuntu opens, decompresses on first launch, and asks you to pick a Linux username and password. You’re done, with a real Linux environment a keystroke from Windows.
What you just installed
WSL2 (Windows Subsystem for Linux, version 2) runs “an actual Linux kernel inside a managed VM,” as Microsoft’s comparison page puts it: a lightweight utility virtual machine you never manage, giving full Linux system-call compatibility. That’s the difference from the older WSL1, which translated Linux calls to Windows ones and broke on anything exotic. In practice WSL2 is Linux (Docker, systemd, native toolchains all behave), with one performance rule attached: keep your working files inside the Linux filesystem (under ~, not /mnt/c/…), because cross-OS file access is the one place WSL2 is slow.
The install, with its edge cases
wsl --install # the whole thing, Ubuntu default
wsl --list --online # see other available distros
wsl --install -d Ubuntu-24.04 # install a specific one
wsl -l -v # confirm: VERSION column says 2
wsl --update # update WSL itselfTwo catches worth knowing before they find you. If WSL is already present, wsl --install prints help text instead of installing (Microsoft’s own note); use wsl --install -d <distro> to add a distribution. And if the first launch fails with error 0x80370102 (or install fails with 0x80070003), that’s virtualization disabled in BIOS/UEFI. The fix lives in firmware settings, usually under CPU options, not in Windows.
The systemd detail that matters for agents
Background services on modern Linux are systemd’s job, and WSL2’s support for it has a wrinkle: it’s the default for the current Ubuntu installed via wsl --install, but other distros may still use WSL’s own init until you opt in. To do that, add [boot] systemd=true to /etc/wsl.conf and run wsl --shutdown. This stops being trivia the moment software wants to install a service: an agent’s daemon, for instance, installs as a systemd user unit on Linux and WSL2 alike, and quietly can’t without systemd running.
WSL2 and agent software
WSL2’s pitch for agent operators is simple: the agent ecosystem is Linux-native, and WSL2 gives Windows machines the real thing. OpenClaw’s Windows story reflects that. Current docs recommend their native Windows Hub app for the desktop experience, but call WSL2 “the most Linux-compatible Gateway runtime on Windows,” and their WSL2 path is exactly this page: install, enable systemd, then the ordinary Linux install (Node included). One caveat carries over from everything being a VM on a PC: a WSL2 environment lives while the PC does. It’s the right way to develop with Linux on Windows; a machine that sleeps, reboots for updates, and travels is still the wrong home for something meant to run around the clock. That’s the reasoning that eventually points agent owners at an always-on machine of the agent’s own.