Windows Now Supports Popular Linux Coreutils Commands

Microsoft has delivered a suite of native Linux-style command-line tools for Windows, and now the cat, cp, and ls commands you normally use in a Linux terminal can run as actual Windows commands instead of being hidden inside a virtual machine.

The normal answer to "How do I get grep working on Windows?" has usually been to install WSL (Windows Subsystem for Linux), download Git Bash, or rely on third-party ports. Now Microsoft is building that functionality directly into Windows.

What makes this interesting is not simply that Linux commands have arrived on Windows, but how they arrived: through a Rust-based rewrite of GNU Core Utilities maintained by Microsoft and designed to run natively on Windows. While this is still an early preview release, there are several important limitations you should understand before depending on it heavily, including naming conflicts, missing commands, and the lack of a full POSIX layer.

What the Linux Coreutils Commands Release Actually Ships

Coreutils for Windows is a Microsoft-maintained collection of UNIX-style command line utilities that run natively on Windows, and right now it is shipping as a preview. The whole set arrives as one multi-call binary. The installer points each command name at that single binary, typically through hardlinks, and the binary decides which tool to run based on the name it was invoked as. So calling cp or ls runs the same underlying executable, just dispatched by name.

Installation is a one-liner through WinGet, or a direct download from the project's GitHub releases. Every command supports the usual --help flag, and the behavior leans on the standard flags and pipelines, so the muscle memory you built on Linux mostly carries over without relearning a Windows-specific clone.

Why It Runs on uutils and Rust

Microsoft did not write a fresh from-scratch implementation. It based this on uutils, the open source Rust project that reimplements GNU coreutils and already ships inside some current distributions. That choice means contributions flow back into a shared cross-platform codebase rather than into a closed Windows fork.

The Rust angle fits a pattern. Memory-safe systems code has been moving into core infrastructure across the ecosystem, including Rust in the Linux kernel, and the same language choices showing up in recent Rust releases are what make a single coreutils codebase practical across Windows, Linux, and macOS. For Linux users the takeaway is simple: the tool you run on Windows is a cousin of the one some distros already ship, not a reinvention.

What Changes When You Move Between Systems

The real win is for people who live in more than one operating system at once. If you write a script on Linux and run it on a Windows build agent, the commands, flags, and pipes now behave consistently instead of forcing translation or a fallback shell. That cuts the friction that pushes developers toward heavier setups just to get familiar tooling.

Microsoft describes the aim plainly: the project is built to "remove friction when moving between Linux, macOS, WSL, containers, and Windows."

Microsoft Coreutils for Windows documentation, June 2026

Microsoft also left the native Windows find.exe and sort.exe untouched in System32, so older scripts that rely on them keep running as before. It also helps to see where this sits next to the older ways of getting Linux commands on Windows, since each approach still has a place. Interoperability projects like Samba file sharing solved one slice of Windows and Linux coexistence, and native coreutils solves another at the command line level.

The Enterprise and WSL Container Angle

This landed as part of a wider Windows-as-developer-platform push. Microsoft also introduced WSL containers, which let developers create, run, and deploy Linux containers directly through WSL, plus APIs so native Windows apps can manage those containers programmatically. WSL has had real momentum since Microsoft expanded its open-source governance, with the company reporting more than 200 pull requests a month from contributors.

For teams there are admin controls too: approved container image sources, usage monitoring, and managed interaction between Linux containers and the Windows host. That governance framing is the same instinct you see in enterprise Linux lifecycle planning, and it is a sign Microsoft expects this in regulated shops, not just on hobbyist machines. None of it changes how you run Linux itself, so your distro choice, whether that is the best Linux distro for 2026 or something older, is unaffected.

What Is Still Unclear

The biggest thing to understand is naming. A native cat, ls, or mv now shares a name with PowerShell aliases and built-in commands, so which one actually runs depends on your shell, your PATH order, and the PowerShell alias table. To avoid breaking core Windows behavior, a handful of commands are simply not shipped, including dir, more, whoami, expand, and paste.

Linux admins will spot bigger gaps. Because Windows has no POSIX system layer, a long list of standard utilities is excluded outright, among them chmod, chown, chroot, kill, nohup, tty, who, and timeout. Some of that is structural rather than a choice: without POSIX signals there is no clean way to implement kill, and timeout leans on it. If your scripts assume those tools exist, they will not behave differently, they will not be there at all.

There are quieter surprises too. Line endings default to CRLF, /dev/null becomes NUL, and file permissions ride on Windows ACLs rather than POSIX bits, so a check like find -perm may not mean what you expect. The project is still in preview, so the sensible move is to test against it now rather than pin a release pipeline to it this week.