Hermes keeps stumbling on Windows command line? Start with these 78 commands

Have you ever had this happen: you ask Hermes or Claude Code to find all TODOs in a Windows project, and it naturally writes grep -R "TODO" ., then follows up with ls -la to look at the directory. The commands look fine, but PowerShell replies with “not recognized” or quietly returns a different result.

At that point, many people’s first reaction is “The agent just doesn’t understand Windows.”

I think that’s only half true. Agents do often assume they’re in a Unix-like terminal, but the real headache is that Windows’ native terminal has long struggled to understand those common commands. If you ask someone used to speaking Mandarin to mentally translate into another dialect before every sentence, they’ll be slower and occasionally get it wrong.

On June 2nd, Microsoft did something quite un-Microsoft: they packaged 78 Unix-like commands as a native Windows toolkit. This is not WSL, not Cygwin, not the bundled commands in Git Bash. The maintainer is Microsoft, the project is called Coreutils for Windows, hosted at GitHub repository microsoft/coreutils, under MIT license, installable with a single winget command. It quickly reached 3.7k stars after release.

What I really want to point out is that this shouldn’t just be seen as “Windows finally has ls”. For people using terminal agents, it’s more like providing a common dictionary for the Windows native environment. From now on, when an agent does file searching, log viewing, or text processing, it won’t have to translate grep into Select-String, ls into Get-ChildItem, or tail into some PowerShell snippet every single time.

The short answer: If you use Hermes, Claude Code, or Codex in a Windows native terminal, first confirm you have PowerShell 7.4, then install Microsoft Coreutils. For initial verification, don’t just type ls; use the explicit .exe forms like ls.exe, grep.exe, tail.exe.

The problem isn’t that the agent is dumb

Let’s get this scenario clear. You ask the agent to search for a term in the project, it writes grep. You ask it to look at the last few dozen lines of a log, it writes tail. You ask it to count file lines, it writes wc -l. These commands are everyday language in Linux, macOS, Docker containers, and countless open-source project docs—the agent isn’t just making things up.

The trouble is on Windows’ side. PowerShell has its own complete set of commands and object pipeline, which is powerful and even better suited for managing services, registry, and processes on Windows. But most training data for agents, open-source project instructions, CI scripts, and developer habits naturally lean toward Unix-like commands. Neither side is wrong; what’s missing is a translation layer—or rather, that translation layer has always been pushed onto the user and the prompt.

In the past, you had roughly three options. First, repeatedly remind in the prompt: “This is Windows, please use PowerShell syntax.” Second, switch to WSL and put the whole working directory in a Linux environment. Third, write your own compatibility scripts to map names like ls, grep, find to Windows commands.

All workable, but all awkward.

Prompt reminders get forgotten. WSL brings new issues with paths, drive letters, permissions, file sync. Compatibility scripts feel like assigning a separate translator for each project. What Microsoft did this time is straightforward: instead of first asking the agent to be smarter, they made Windows native terminal learn a set of words the agent already knows well.

Don’t rush to install — first spend 10 seconds checking your PowerShell version

Before installing, do one small thing: open the terminal you normally use and run this line:

$PSVersionTable.PSVersion

If you see Major 7, Minor 4 or higher, proceed. If you see Major 5, stop. That’s usually the old Windows PowerShell 5.1, not the PowerShell 7.4+ environment required by the current docs. The names differ only by “Windows”, but they’re like an old elevator and a new elevator in the same building—if you’re at the wrong door, nothing works from there.

No need to panic if you have the old version. Install the new PowerShell using winget:

winget install --id Microsoft.PowerShell --source winget

After installation, search for “PowerShell 7” in the Start menu, or manually switch to the new profile in Windows Terminal. Run $PSVersionTable.PSVersion again to confirm the version before continuing.

Don’t skip this step. Many Windows terminal problems boil down to “I thought I opened the new version, but it’s still the old window.” Everything—whether coreutils can be found, whether PATH is updated, which shell the agent actually runs in—depends on you confirming the current environment first.

Once Windows native terminal gains these common Unix-like commands, the agent has one less translation layer to deal with.

Installation is one command; the pitfalls come after

After confirming the version, the install command is simple:

winget install Microsoft.Coreutils

Follow the prompts. The real trouble often starts after installation. The current terminal window might not have refreshed its PATH. A user on the SANS ISC article noted that after winget install, the new path didn’t immediately appear in the current shell.

So I recommend you close the current PowerShell after installation, then open a new window. Don’t rush to type bare ls. First, explicitly call the program files:

grep.exe --help

If help text prints, the system can find coreutils’ grep.exe. Then run:

ls.exe -la

If it lists the current directory files, then basic path and execution permissions are working. If one command fails, don’t immediately uninstall and reinstall. First check whether the system can find it:

Get-Command grep.exe

If you see a specific path, it’s likely just an old window not refreshed or a wrong shell environment. If it’s not found at all, then go back and check the winget installation result.

The success signal is simple: grep.exe --help shows help text, ls.exe -la lists the directory, and the terminal doesn’t complain about unrecognized commands. At that point, the tool itself is ready.

The easiest way to trip: PowerShell already owns those names

Here’s a trap that many people think they’ve avoided but actually haven’t.

PowerShell already has a set of short aliases. ls points to Get-ChildItem, cat to Get-Content, cp to Copy-Item, rm to Remove-Item, pwd to Get-Location. After you install Coreutils, these aliases don’t automatically step aside.

The result is subtle. When you type ls, the screen does list files, but it might not be running coreutils’ ls.exe—it could still be PowerShell’s own alias. You think the new tool is active, the agent thinks it’s using a Unix-like command, but in reality it’s still getting routed back through PowerShell.

The way to confirm is simple:

Get-Command ls

If the result says Alias, then ls is still occupied by PowerShell. Don’t rush to delete aliases right away. Just use the .exe suffix explicitly:

ls.exe -la
grep.exe -R "keyword" .
tail.exe -n 20 .\app.log
cat.exe .\README.md

I don’t recommend bulk-deleting PowerShell aliases immediately after installation. PowerShell’s native commands return objects and are very valuable for working with Windows services, registry, processes, and system configuration. Coreutils excels at traditional text pipelines. It’s not about eliminating one for the other; it’s more like having a Chinese chef’s knife and a Western chef’s knife in the kitchen. Your job is to tell the agent when to use which, not to throw one away.

Especially with rm.exe. rm and rm.exe are not the same implementation; arguments and confirmation behavior may differ. For your first test, don’t practice with real data directories.

First verify with 3 read-only commands, then hand it to the agent

Create a test folder with a few text files, a README, and a log file. For the first pass, only view and search—no copying, moving, or deleting anything.

First, list the directory:

ls.exe -la

Then, search text:

grep.exe -R "TODO" .

Finally, view the tail of a log:

tail.exe -n 20 .\app.log

These three steps verify directory listing, recursive search, and log viewing. If they all pass, then the installation helps with the three most common agent actions. The key word here is read-only: first make sure the system says “I can see”, then talk about “I can modify.”

Next, give the same three tasks to Hermes or Claude Code. You can paste this environment note directly to it:

Current environment is Windows PowerShell 7, with Microsoft Coreutils installed. For directory listing, text searching, and log viewing, prefer Coreutils commands with the .exe suffix, e.g., ls.exe, grep.exe, find.exe, tail.exe. This operation is limited to the test directory only—no modifying, moving, or deleting any files.

Watch what it actually executes. If it still writes just grep or uses Bash-specific syntax, it doesn’t yet know the new boundaries of this Windows machine. Don’t blame the tool at that point. Put this environment note into an AGENTS.md file in your project root, or into your regular terminal agent’s project rules.

Installing the tool is just putting the dictionary on the table. Whether the agent opens it depends on you clearly stating the rules.

First confirm PowerShell version and PATH, then let the agent handle project commands.

If the agent still fails after installation, check these 5 layers

If manual commands work but the agent fails, don’t jump to rewrite a long prompt. Check in order; you’ll usually find the cause quickly.

Layer 1: Confirm which shell the agent is in. You might be in PowerShell 7 manually, but that doesn’t mean the agent is in the same environment. It could be running in CMD, Git Bash, WSL, or even a terminal spawned by some tool. Ask it to run $PSVersionTable.PSVersion or Get-Command grep.exe—don’t just look at your own window.

Layer 2: Confirm PATH. Run Get-Command grep.exe manually, then have the agent run the same command from the same directory. If you find it but the agent doesn’t, it’s likely that the environment variables it inherited haven’t refreshed. Restarting the agent process is more useful than repeatedly reinstalling.

Layer 3: Check for the .exe suffix. PowerShell aliases can hijack command names. Writing grep.exe, ls.exe, tail.exe is cleaner. Once you confirm all common commands are stable, then decide whether to let the agent use bare command names.

Layer 4: Check quotes and paths. Windows paths can contain spaces, Chinese characters, and backslashes. Many Linux-looking commands choke on escaping issues. Copy the command the agent generated, run it manually from the same directory—the error message will be more reliable than the chat’s summary.

Layer 5: Check if the task is beyond Coreutils’ scope. Finding files, searching text, viewing logs, calculating checksums, sorting, deduplicating—these are great. Full Bash scripts, package managers, Linux service management, complex permissions, and background daemons—don’t expect this toolkit to cover everything. If you need WSL, go to WSL. If you need PowerShell native commands, use PowerShell.

After checking these five layers, you’ll stop getting stuck in vague questions like “Is the agent dumb or is Windows broken?” The problem becomes specific: wrong shell, wrong PATH, alias collision, path escaping error, or the task simply needs a different environment.

Write the command boundaries into your project documentation so the agent knows when to use .exe.

Are 78 commands enough? Depends on what you ask the agent to do

Among these 78 commands, the most commonly used ones already cover the daily work of a terminal agent. ls, cat, head, tail, grep, find, xargs, sort, uniq, cut, tr, wc, sha256sum, md5sum, du, df, stat—these are the file and text processing tools agents love to pull out first.

If your tasks are looking at logs, searching for errors, counting files, checking checksums, or viewing directory sizes, Coreutils is very useful. It saves you from moving your whole project into WSL, and from teaching the agent PowerShell’s object pipeline. For many read-only checks and lightweight scripts, removing that translation layer makes the experience much smoother.

If your tasks involve running full Linux projects, depending on apt or yum, needing systemd, or requiring the Linux permission model, continue using WSL. Coreutils is not a miniature Linux; it just migrates a batch of common commands to the Windows native environment. Don’t overestimate its boundaries, or you’ll be disappointed.

If your tasks involve managing Windows services, registry, scheduled tasks, and object data, PowerShell native commands are still more appropriate. Get-Service, Get-Process, Get-ItemProperty—these are Windows’ own language. Trying to force Coreutils to manage Windows systems is like using a chef’s knife to turn a screw—possible, but unnecessary.

So the decision to install shouldn’t be based on the number 78, but on what you normally ask your agent to do. If you frequently search files, search text, and view logs in native Windows projects, it’s worth installing. If you only occasionally open a terminal to type a couple of commands and don’t use an agent, there’s no need to bother with the news.

A command that works doesn’t mean scripts are fully cross-platform

Let me pour some cold water here. ls.exe works, but that doesn’t mean you can take a script from Linux and run it unchanged on Windows.

The underlying differences between Windows and Linux still exist. Text line endings might be CRLF, the null device is NUL not /dev/null, permission models aren’t the rwx bits, symbolic links may require developer mode or admin privileges, and PowerShell’s escape rules aren’t Bash’s. When paths contain spaces, Chinese characters, or backslashes, older scripts still need to be tested line by line.

Microsoft itself labels this project as Preview. That word doesn’t mean “don’t use it,” but it’s a reminder not to gamble with production directories. The safest order: start by running read-only commands in a test directory to confirm output, then test copying and file generation, and only then test moving and deleting. Commands like rm.exe should be last, and only used in a test directory you specifically created.

I see it as a very useful stepping stone, not a magic button that turns Windows into Linux. The value of a stepping stone is precisely that it helps you cross the first puddle—but the path ahead still depends on the terrain.

Is now the right time to install?

If you frequently use Hermes, Claude Code, or Codex in a Windows native terminal, my suggestion is: yes, you can try it now. Officially maintained, installed via winget, MIT licensed, command list public—the source is much cleaner than randomly finding a green portable toolkit from the web. The preview version has pitfalls, but most can be caught by the verification steps above.

Don’t be greedy the first time. First confirm PowerShell 7.4, then winget install Microsoft.Coreutils, reopen the terminal, and do read-only verification with grep.exe --help, ls.exe -la, tail.exe -n 20. Then write the environment note into AGENTS.md, telling the agent to prefer coreutils commands with the .exe suffix in Windows PowerShell 7.

Once read-only tasks are stable, let it handle copying, file generation, and lightweight text transformations. Leave delete, move, and overwrite actions for last, and only in a test directory. When you need a full Linux environment, don’t tough it out—switch to WSL. When you need Windows system administration, don’t take a detour—use PowerShell.

Microsoft stuffed 78 Unix-like commands into Windows, and the most practical result isn’t that Windows becomes Linux; it’s that terminal agents on Windows finally have one less translation to do. One less translation sometimes means one less error, one less prompt tweak, one less time dragging a perfectly good automation task back to manual patching.

That alone makes it worth trying.