Can Windows’ New Native Linux Commands Replace WSL?

Coreutils Installation and Single‑File Design

At the recent Build 2026 conference Microsoft released a Windows‑native Coreutils package built from the open‑source uutils project (written in Rust). The tools are bundled into a single executable coreutils.exe. During installation the package creates NTFS hard links such as ls.exe, cp.exe, cat.exe that all point to the same core executable, so invoking any command loads coreutils.exe and dispatches based on the called name.

Installation can be performed automatically from PowerShell with the WinGet command:

winget install Microsoft.Coreutils

Terminal Conflicts and Compatibility

Many of the bundled commands (ls, cat, cp, mv, rm, pwd, sleep, tee, etc.) clash with built‑in Windows commands or PowerShell aliases. Microsoft published a compatibility table that shows how each tool behaves in different terminals. Whether a command works depends on the terminal type, the order of directories in the PATH environment variable, and any PowerShell alias that may override the name.

Commands such as dir, more, paste and whoami were omitted because they conflict with native Windows commands.

Feature Trade‑offs and Their Rationale

Tools that rely on POSIX interfaces—chmod, chown, chroot, nohup, tty, who, kill, timeout—are not included because Windows lacks the underlying permission model and signal mechanisms. Microsoft notes that signal‑related commands may be added in the future.

The documentation warns that the same command can produce different results on Linux versus Windows due to differences in line‑ending formats, file‑permission handling, and POSIX compatibility.

Rational View of the Shortcomings

Although Coreutils improves the developer experience on Windows, it cannot completely replace WSL. Missing POSIX capabilities (e.g., chmod, kill) limit its use to simple file manipulation and text processing. Command‑name conflicts and PATH/alias interactions can cause unexpected behavior, and underlying differences in newline handling, path syntax, and permission semantics mean complex scripts or software that depend on deep Unix semantics still require WSL.

Consequently, for running Linux‑only services, full build environments, containers, or software that depends on system calls, WSL remains necessary.