Microsoft has tried to graft Unix onto Windows at least three times since 1996, and each attempt got quietly retired within a decade. Coreutils for Windows, unveiled at Microsoft’s Build 2026 developer conference and installable with a single WinGet command, is the fourth attempt, and the first one that does not need a subsystem, a kernel or a separate environment to work.
That distinction matters more than it sounds. The earlier efforts, from a 1990s startup’s POSIX layer to the modern Windows Subsystem for Linux (WSL), all asked Windows to host something foreign underneath it. Coreutils for Windows just installs native binaries and gets out of the way, which is why a Linux system administrator writing for XDA Developers described dropping the WSL tab he had pinned in Windows Terminal for years, reaching for it now only when a job genuinely needs a full Linux kernel.
A WinGet Install Replaces a Decade of Workarounds
Getting the package takes one line in PowerShell: winget install Microsoft.Coreutils. After a terminal restart, dozens of familiar commands show up on the PATH. Microsoft packaged the tools as a single multi-call binary that exposes each utility under its standard name, cat.exe, grep.exe, find.exe and more, covering upward of 75 Unix-style command-line tools in total.
Under the hood, the package bundles uutils, a Rust reimplementation of GNU coreutils, alongside findutils for find and xargs, and a newly written GNU-compatible grep. Because that lineage traces back to the same tools Linux distributions already ship, the flags, output formatting and sort order match what a Linux or macOS user expects, so scripts do not need translation.
Some tools were left out on purpose. chmod, chown and chroot never made the cut, since Windows does not track file ownership and permission bits the way Unix systems do, and there is no clean way to fake that mapping. Microsoft Learn’s own Coreutils for Windows overview page lists the package as a preview release, distributed through WinGet and mirrored on GitHub.
Windows Has Tried This Unix Trick Before
This is not Microsoft’s first swing at Unix compatibility, and the earlier swings did not age well.
- 1996: Softway Systems ships Interix as OpenNT, an independent, POSIX-compliant Unix layer built to run on Windows NT.
- 1999: Microsoft buys Softway Systems outright and absorbs Interix into its own compatibility roadmap.
- Early 2000s: Microsoft folds Interix into Services for UNIX and strips the original POSIX subsystem out of the Windows kernel and base install entirely, timed to the Windows XP and Windows Server 2003 era.
- Windows 10 era: The Windows Subsystem for Linux takes over, and Interix-based tooling is retired for good on Windows 10 and Windows Server 2019.
- 2026: Coreutils for Windows debuts at Build as a native WinGet package, with no subsystem or virtual machine underneath it.
Each prior attempt eventually got cut loose because it demanded real architectural weight, a bundled subsystem, a POSIX personality bolted onto the NT kernel, later a full virtualized Linux kernel, just to hand someone a working copy of grep.
The Difference Is What Runs Under the Hood
WSL still routes filesystem access through a kernel translation layer, and that overhead shows up on commands like grep and find once a directory holds a few thousand files. Coreutils for Windows skips that layer completely, since the binaries run as ordinary native Windows executables. The XDA piece that prompted this story called the speed difference on recursive searches obvious once you stop paying the translation tax.
Compatibility held up too. Older batch scripts built around the legacy Windows versions of sort and find kept working side by side with the new Unix commands during testing, since the two sets of tools do not collide on the same names in practice.
Microsoft’s broader developer strategy has been leaning the same direction lately. Its Linux-based RTX Spark development boxes aimed at coders already bet that keeping Unix-shaped tooling close at hand, rather than forcing a detour through a separate environment, is what keeps developers from drifting toward a Mac or a straight Linux box.
Five Years of uutils Just Found Its Biggest Customer
The tools inside the package are not new. uutils has spent roughly five years rewriting GNU’s core Unix utilities in Rust, an MIT-licensed effort that now carries more than 23,000 GitHub stars and contributions from 530 different people on the coreutils component alone. The project’s own writeup on extending the rewrite beyond coreutils lays out the same goal Microsoft is now shipping: drop-in GNU compatibility with a memory-safe codebase underneath it. As of this year the project sits at version 0.8.0, and its maintainers claim commands like cat run up to 15 times faster than GNU’s version on sequential reads.
Microsoft is not the only major platform betting on that codebase. Canonical is threading the same Rust rewrite through Ubuntu on a nearly identical timeline.
| Release | Status | Rust Coreutils Role |
|---|---|---|
| Coreutils for Windows (2026) | Preview, via WinGet | Optional native package alongside cmd and PowerShell tools |
| Ubuntu 25.10 | Released | Initial, opt-in rollout of uutils |
| Ubuntu 26.04 LTS | Current default | Default for most core utilities |
| Ubuntu 26.10 | Upcoming | Targeting full, 100 percent Rust coreutils coverage |
A side project that spent years being the answer to “why would anyone rewrite grep” now sits underneath the default terminal experience on two of the biggest desktop platforms in the world, at nearly the same moment.
Where WSL Still Wins
Coreutils for Windows was never built to replace WSL, and Microsoft says so directly.
WSL remains the best solution for running Linux binaries, daemons, and GUI apps.
That line comes straight from Microsoft’s own Coreutils for Windows documentation, and it matches what the XDA piece found in daily use: anything heavier than a one-off command still means opening WSL.
- File permissions: chmod, chown and chroot are absent because Windows does not track Unix-style ownership bits.
- Containers and full dev stacks: a real development environment built on containers and background services still needs WSL’s Linux kernel.
- Daemons and background services: anything that needs to run as a persistent Linux process stays on WSL.
- Graphical Linux apps: those still route through WSLg, not through Coreutils.
Coreutils for Windows was built for the other 90 percent of the day, the quick grep, the one-off find, the script that should not care which operating system runs it.
Is Microsoft Quietly Retiring WSL?
No, not based on anything Microsoft has said or shipped so far. Coreutils for Windows still carries a preview label, with no announced date for a stable release, and Microsoft has attached no deprecation timeline to WSL itself.
Reaction among developers has mostly run positive since Build. One tester on Microsoft’s Windows Insider forums wrote that it felt “surreal to run grep from cmd.exe and have it just work,” calling it “the final piece of the puzzle after Terminal and WSL.” A smaller, more cautious group of longtime WSL users have raised a different worry: that native tools are the first step toward Microsoft eventually scaling back its investment in WSL altogether.
Nothing in Microsoft’s own positioning supports that yet. The company has repeatedly framed Coreutils as an addition sitting next to WSL, not a successor to it, and the missing pieces, containers, daemons, GUI apps, are exactly the workloads WSL was built to own.
Frequently Asked Questions
Is Coreutils for Windows free to use?
Yes. The uutils core is MIT-licensed open-source software, Microsoft distributes the Windows build at no cost through WinGet, and the packaging code is public on GitHub.
Does it work in PowerShell, or only Command Prompt?
It works in both, along with Windows Terminal. Because the tools install as ordinary native executables on the system PATH, any shell that reads the PATH can call them the same way.
Does this replace Cygwin, MSYS2 or Git Bash?
Not directly. Those long-running community projects emulate a broader slice of POSIX behavior, including process forking, that Coreutils for Windows does not attempt. Coreutils covers the common command set natively; the older compatibility layers still exist for anyone who needs deeper POSIX emulation.
What does Microsoft mean by a multi-call binary?
It means one executable file does the work of dozens of commands, deciding which behavior to run based on the name it is invoked as, similar to how BusyBox works on embedded Linux systems. That is how a single install adds cat, ls, grep, find and more without dozens of separate executables cluttering the system.
