Lima v2.3: Native on Windows, VMnet on Linux, and menu TUI

The Cloud Native Computing Foundation project Lima released version 2.3 on November 6, 2026, delivering standalone virtualization capabilities across Windows, Linux, and macOS host systems. The open-source virtual machine utility, which originally started as a macOS container management runtime before entering the CNCF Sandbox in September 2022 and advancing to Incubating status in October 2025, now provides a native Windows driver built directly on Microsoft's Host Compute System. According to details shared in the CNCF Blog's report, this release eliminates the requirement for QEMU or a Unix toolchain when starting local virtual environments on Windows hosts, while also bringing routable network bridges to Linux, direct physical block device attachment to macOS Virtualization.Framework guests, and an experimental interactive terminal user interface called limactl menu.

This breakdown outlines the architectural improvements, configuration rules, driver constraints, and operational adjustments introduced in Lima v2.3 for systems engineers, infrastructure developers, and developers running isolated local software environments. It explains the migration steps required to configure administrative permissions on Windows, deploy privileged network helpers on Linux, attach raw external drives on macOS, and restrict directory synchronization when orchestrating artificial intelligence coding agents inside sandbox virtual machines.

What Native on Windows, VMnet on Linux, and menu shipped

Lima v2.3 introduces an experimental hcs driver on Windows that interfaces directly with the Windows Host Compute System application programming interface, which is the underlying virtualization platform powering WSL2. This mechanism allows developers to boot virtual machines without running QEMU or maintaining external emulation toolchains, expanding upon the basic Windows guest support originally added in Lima v2.2 in July 2026. The Windows implementation also gains native handling for Windows file paths, native support for the built-in Windows OpenSSH client, and automated discovery of default QEMU installation directories under the Program Files folder. Additionally, Windows guests now support startup customization through system, user, data, and dependency provisioning scripts.

For Linux host operators, the release ships lima-privileged-net, a dedicated root helper binary designed to mirror the direct host-to-guest IP reachability that macOS users historically accessed via socket_vmnet. This tool manages the creation of Linux bridge interfaces, attaches per-instance tap devices, and launches dnsmasq to handle Dynamic Host Configuration Protocol assignments, Domain Name System queries, and network address translation routing for shared networks. Alongside host-level updates, Lima v2.3 introduces limactl menu, an interactive terminal user interface that presents color-coded virtual machine listings, display metrics for assigned processor cores and memory, shell access triggers, and confirmation-guarded lifecycle controls.

What changed for builders in Native on Windows, VMnet on Linux, and menu

Software builders running workflows on Windows no longer need to depend strictly on the wsl2 driver or manage manual PATH variable entries for QEMU installations, enabling a stock Windows setup to execute limactl shell, limactl copy, and reverse-sshfs directory mounts seamlessly. macOS builders utilizing Apple's Virtualization.Framework can now bypass intermediate file shares entirely by attaching real physical external solid-state drives, USB storage keys, or RAM disks directly to VZ guests via the virtio-blk interface, presenting the underlying storage under the guest dev filesystem hierarchy as virtio disk identifiers.

For developers deploying autonomous artificial intelligence agents inside isolated virtual sandboxes, Lima v2.3 enhances security during file transfer routines. The limactl shell sync workflow previously copied an entire project tree unconditionally into the target virtual machine before requesting sync confirmation; the newly added sync-exclude argument lets builders omit sensitive or heavy directories such as environment secret files, git tracking metadata, and dependency folders.

How to install or upgrade Native on Windows, VMnet on Linux, and menu

Upgrading or installing Lima across different platforms utilizes standard package distribution managers or direct binary extractions depending on the target host operating system. macOS users managing packages via Homebrew can install the latest release directly:

brew install lima

Windows developers can install Lima through PowerShell using the Windows Package Manager:

winget install Lima.Lima

Starting an instance with the new experimental HCS driver on a Windows workstation requires enabling hardware virtualization, adding the target Windows user account to the Hyper-V Administrators group from an elevated administrative PowerShell prompt, and restarting the shell:

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

Linux hosts deploying the new privileged network helper must install Lima and dnsmasq as root, generate the sudoers policy, and validate permissions before starting instances on the managed shared bridge:

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

To run the new interactive terminal menu interface across any supported host environment, execute the interactive command:

limactl menu

Gotchas and compatibility in Native on Windows, VMnet on Linux, and menu

The experimental hcs driver on Windows contains strict operational boundaries in this initial iteration. Virtual machines must be launched exclusively in plain mode, meaning dynamic port forwarding and directory mount systems are unavailable until future updates. Furthermore, because the Host Compute Network subnet assignment is currently fixed, operators can run only a single HCS instance simultaneously, and an explicit external Domain Name System resolver such as 8.8.8.8 must be declared at startup. For Windows guest machines, provisioning script support is restricted to system, user, data, and dependency categories; boot, yq, and ansible provisioning modes remain unsupported.

On macOS, direct block device access requires strict adherence to privilege controls to prevent filesystem corruption and security breaches. External storage disks must be unmounted through diskutil prior to starting the guest, otherwise macOS will lock the volume and cause the virtual machine startup sequence to fail with a resource busy error. Additionally, developers must extract Lima into root-owned paths under the opt directory, manually inspect the generated sudoers entry with visudo, and ensure host operating system boot disks are never passed to virtual guests. Nested virtualization using the HVF accelerator on 64-bit ARM hardware requires macOS version 15 or later combined with QEMU version 11.1 or higher.

What to watch after Native on Windows, VMnet on Linux, and menu

Infrastructure engineers should monitor the progression of the Windows HCS driver as development proceeds beyond the current plain-mode limitations. Subsequent releases aim to resolve the hardcoded Host Compute Network subnet constraints that presently block concurrent multi-instance HCS deployments, while also expanding guest provisioning configurations toward full parity with Linux guest environments.

On Linux and macOS, tracking the integration of privileged helpers into enterprise distribution packages will indicate how smoothly automated bridge creation and raw storage passthrough can be embedded into continuous integration pipelines. For macOS Virtualization.Framework environments, developers should also observe refinements to snapshot handling under the krunkit driver as well as potential expansions of audio capture input options for containerized testing rigs and sandboxed agent runtimes.