Fix PowerShell "is not recognized as the name of a cmdlet, function, script file, or operable program"

What's happening

You run a command and PowerShell slaps you with this:

foo : The term 'foo' is not recognized as the name of a cmdlet, function, script file, or operable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.

Translation: PowerShell searched every directory it knows about and came up empty. The fix depends on why it can't find the command — missing PATH entry, unloaded module, wrong shell, or execution policy blocking a script.

Diagnose before you fix

1. Check if the command exists at all

Start with Get-Command:

Get-Command foo

No output means PowerShell genuinely doesn't know about it. A path in the output means the binary exists but something else is wrong — permissions, corrupted install, or a version mismatch.

2. Check what's in your PATH

$env:PATH -split ';'

Scan the list for the directory where your tool lives. Missing from the list? That's almost certainly the problem.

3. Confirm where the binary actually is

# Example for a CLI tool installed to a custom path
Test-Path "C:\Tools\mytool\mytool.exe"

True means the file exists — it just isn't on the PATH yet.

Fix 1: Add the missing directory to PATH

Nine times out of ten, this is the culprit. Add the directory permanently for your user account:

# Append to user PATH — survives reboots
$dir = "C:\Tools\mytool"
$current = [Environment]::GetEnvironmentVariable("PATH", "User")
if ($current -notlike "*$dir*") {
    [Environment]::SetEnvironmentVariable("PATH", "$current;$dir", "User")
    Write-Host "Added $dir to PATH"
} else {
    Write-Host "Already in PATH"
}

Close and reopen PowerShell after running this. The current session won't pick up the change.

Need it to work right now without restarting? Use this one-liner — it lasts only for the current session:

$env:PATH += ";C:\Tools\mytool"

Verify the fix

Get-Command mytool
mytool --version

Fix 2: Execution policy blocking a .ps1 script

Running a .ps1 script by name without a path prefix will trigger this error. So will a Restricted execution policy, which blocks all scripts by default.

# Check current policy
Get-ExecutionPolicy

# Allow locally-written scripts (safe for dev machines)
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

PowerShell doesn't search the current directory for scripts the way cmd.exe does. Always call local scripts with an explicit path:

# Wrong — PowerShell ignores the current directory for script lookup
myscript

# Correct
.\myscript.ps1
# or full path
"C:\Scripts\myscript.ps1"

Fix 3: Module not imported

Plenty of cmdlets ship in modules that aren't loaded by default. Connect-AzAccount, Get-AzVM, and most vendor cmdlets fall into this bucket.

# See which modules are currently loaded
Get-Module

# Find available modules matching your cmdlet
Get-Module -ListAvailable | Where-Object { $_.Name -like "*Az*" }

# Load it
Import-Module Az.Accounts

If the module isn't installed yet, grab it from the PowerShell Gallery first:

Install-Module -Name Az -Scope CurrentUser -Force

Then re-run your original command.

Fix 4: You're in the wrong shell

cmd.exe and PowerShell aren't interchangeable. A quick sanity check:

# Run this — a version number means you're in PowerShell
$PSVersionTable.PSVersion

# Error? You're in cmd.exe. Launch PowerShell:
powershell
# Or for PowerShell 7:
pwsh

One more gotcha: Windows PowerShell 5.1 and PowerShell 7 are separate installs with separate module directories. A module installed under 5.1 won't show up in 7, and vice versa. You'll need to reinstall it for the other version.

Fix 5: Typo or wrong command name

PowerShell cmdlets follow a strict Verb-Noun pattern. If you're unsure of the exact name, search for it:

# Partial name search
Get-Command *process*
Get-Command -Verb Get -Noun *service*

# Or just press Tab after typing the first few letters

Fix 6: Command installed for a different user or scope

Per-user installers — npm global packages, pip, Scoop, and others — drop binaries into user-specific directories that often aren't on the system PATH.

# npm: find the global bin directory
npm config get prefix
# Typical output: C:\Users\you\AppData\Roaming\npm
# That folder needs to be in your PATH

# pip: find the user scripts directory
python -m site --user-scripts

Copy the path from the output and add it using the method in Fix 1.

Verification checklist

• Run Get-Command <toolname> — it should return a result with a valid path
• Run the command directly — no "not recognized" error
• Open a new PowerShell window and run it again — this confirms the PATH change is persistent, not just session-level
• If it was a module issue, Get-Module should now list the imported module

Lessons learned

• PowerShell does not search the current directory for executables (unlike cmd.exe). Local scripts need an explicit .\script.ps1 prefix.
• PATH changes via System Properties or [Environment]::SetEnvironmentVariable require a new shell session. The in-session $env:PATH trick is temporary only.
• PowerShell 5.1 and PowerShell 7 have separate module stores. Switching between them means reinstalling modules in the other version.
• When an installer claims it "added to PATH", verify it with $env:PATH -split ';'. Some installers silently fail, and others need a full logout before the change propagates system-wide.