Lima 2.3 boots VMs on Windows without QEMU and finally gives Linux VMs a real IP

As of November 6, 2026, Lima boots virtual machines on Windows by talking straight to Host Compute System, the virtualization layer WSL2 itself runs on, with no QEMU and no Unix toolchain. Version 2.3 also gives Linux VMs an IP the host can reach, something only macOS had until now through socket_vmnet. And if you use Lima to sandbox coding agents, you can finally keep your .env out of the box.

Lima (Linux Machines) is the CLI for local VMs that many of us first met as the way to get containerd on a Mac. It has been a CNCF Incubating project since October 2025 and today it is used as much for isolating AI agents as for containers.

01Windows: the hcs driver, native but experimental

Up to 2.2, Windows users had two drivers, wsl2 and qemu. Lima 2.3 adds hcs, which calls the Host Compute System API. It is the most interesting change in the release, but right now it is a preview, and the docs are upfront about it:

• plain mode only: no file mounts and no dynamic port forwarding.
• One hcs instance at a time, because the HCN subnet is fixed.
• You must pass a DNS server explicitly with --dns.
• Only tested on Windows 11 x86_64, and limactl has to run from an Administrator shell.
• It boots from .vhdx; a .qcow2 image is converted automatically.

Setup is two steps: enable virtualization and add yourself to the Hyper-V Administrators group.

net localgroup "Hyper-V Administrators" <user> /add
limactl start --vm-type hcs --plain --dns 8.8.8.8
lima

Without mounts, hcs is good for a clean Linux box that starts fast, not for editing on the host and building in the VM. For that, wsl2 is still the practical choice. The other Windows fixes are useful today: Lima picks up the built-in Windows SSH client, handles Windows paths properly, finds QEMU in its default install directory without PATH edits, and the Windows guests added in 2.2 now accept provision scripts (system, user, data and dependency).

02Linux: shared, host and bridged networks at last

The managed lima: shared, lima: host and lima: bridged networks only worked on macOS. Version 2.3 ships lima-privileged-net, a small privileged helper that creates a bridge per network, runs dnsmasq for DHCP and DNS, adds NAT rules in shared mode and hands each instance its own tap device. It only touches interfaces that follow Lima's naming scheme and tears the network down when the last instance leaves.

The cost is a one-time sudoers setup: Lima must be installed as root (the command refuses to write rules for a helper that isn't root-owned), and you need dnsmasq.

limactl sudoers >etc_sudoers.d_lima
less etc_sudoers.d_lima
sudo install -o root -m 0440 etc_sudoers.d_lima /etc/sudoers.d/lima
rm etc_sudoers.d_lima
limactl start --network=lima:shared --vm-type=qemu

If you test multi-node clusters locally, or anything that needs a real IP, Linux is finally on par with the Mac.

03Agent sandboxes that leak less

This is the part I expect to use most. limactl shell --sync copies your project into the VM so an agent can work on it, then asks whether to sync the changes back. Until now it copied everything, .env, .git and node_modules included. Version 2.3 adds --sync-exclude, repeatable and using rsync's --exclude patterns, or a .limasyncignore file in the project:

limactl shell --sync . --sync-exclude .git --sync-exclude node_modules default

The second leak it closes is the network. By default, the guest can reach anything listening on the host's 127.0.0.1 through host.lima.internal. With networkOpts.hostLoopback: false those connections are refused, so your local database stays out of the agent's reach. The catch is that it only works with the VZ driver, which means macOS. Lima's MCP tools also gain replace, so an agent can make targeted edits inside the guest instead of resending whole files.

04macOS: real disks, handled carefully

VZ guests can now get a block device (an external SSD or a USB drive) with --block-device=/dev/diskN. An earlier implementation was reverted after a security report, and the redesign shows: Lima never opens the disk as root. A separate helper, lima-privileged-block-device, does it, and only for the devices listed in a sudoers file you generate, review and validate yourself. The gotcha is that the helper and every parent directory must be root-owned, and typical Homebrew installs are user-writable. To use this feature you extract the release tarball into /opt/lima and run that limactl. And never grant access to your boot disk.

Rounding out the release is limactl menu, an experimental TUI that lists instances with their status, VM type, CPUs and memory, and lets you open a shell, start, stop or delete them, with a confirmation for anything destructive.

05Installing it

# macOS and Linux with Homebrew
brew install lima
# Windows, from PowerShell
winget install Lima.Lima

There are also MacPorts and Nix packages, plus binaries on GitHub releases to extract under /usr/local. If you plan to use the privileged helpers (lima-privileged-net or the disk one), install from the tarball as root: with Homebrew, limactl sudoers won't let you proceed.

06Before it becomes part of your daily setup

• Check that your existing instances still start after upgrading. An instance's vmType can't be changed, so create a new one to try hcs.
• If you use --sync with agents, add a .limasyncignore with .env, .git and heavy directories before your next session.
• On Linux, read the file limactl sudoers generates before installing it: it grants root to one specific binary, which must be root-owned.
• On macOS, set networkOpts.hostLoopback: false in the templates you use as sandboxes.

07Sources

• Lima v2.3: native on Windows, VMnet on Linux, and menu TUI (CNCF, November 8, 2026)
• HCS driver (Lima docs)
• Installation (Lima docs)