Home / Guides / Troubleshooting / Windows

"ollama is not recognized as an internal or external command"

Windows

Written by Jakub Rusinowski · Last updated September 1, 2026

AI educator & workshop leader on local LLM deployment

The error

'ollama' is not recognized as an internal or external command, operable program or batch file.

ollama : The term 'ollama' 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.

Which one is it?

If you see	The cause is	Go to
The terminal was already open when you installed Ollama	A running process keeps the environment block it started with	Fix 1: close and reopen the terminal
It works in a normal terminal but not in an Administrator one	The elevated shell reads a different user account's PATH	Fix 4: stop using an Administrator shell for this
`$env:Path` has no Ollama entry even in a fresh terminal	The installer's PATH entry did not land, or was removed	Fix 3: re-add it in Environment Variables
The directory `%LOCALAPPDATA%\Programs\Ollama` does not exist	The install did not complete, or went to a custom /DIR location	Fix 2: find where the binary actually is
You need it in a service, a scheduled task or CI	A per-user PATH is not visible to LocalSystem or another account	Fix 5: use the standalone zip on the machine PATH

When you see it

The tray icon is there, the app window opens, models download through the GUI — and the terminal insists the command does not exist. The two halves of Ollama have not fallen out with each other; your shell simply does not know where the binary lives.

You installed Ollama with a PowerShell or cmd window already open and typed the command into that same window.
You right-clicked your terminal and chose "Run as administrator" because a tutorial said to.
You installed with OllamaSetup.exe /DIR= to a custom path and the PATH entry points elsewhere.
You are trying to call ollama from a scheduled task, a Windows service, or a CI runner.
Another user account on the same machine installed it.

What's actually going on

Ollama on Windows installs per-user, into your home directory, without Administrator rights — a deliberate choice that makes it installable on locked-down machines. The binaries land in %LOCALAPPDATA%\Programs\Ollama and the installer adds that directory to your user PATH, not the system PATH. Two consequences follow, and between them they explain nearly every report of this error. First, a process inherits its environment block when it starts and never re-reads it, so a terminal that was open during the install still holds the old PATH and will until you close it. Second, an elevated shell runs as a different security context with a different user PATH — which is why "run as administrator", the reflex fix for most Windows problems, makes this one strictly worse.

How to fix it

1. Close the terminal and open a new one

This fixes it more often than everything else on this page combined, and it takes three seconds. Close every open terminal window — including tabs inside Windows Terminal, which share the host process — then open a fresh one and try again. If you use VS Code's integrated terminal, restart VS Code itself, because the terminal inherits the editor's environment block, not a fresh one.

PowerShell

# PowerShell, in the NEW window
ollama --version

Did it work? It prints a version string. If it does, you are done — nothing was actually broken.

ollama --version

2. Check whether the Ollama directory is on your PATH

If a fresh terminal still cannot find it, look at the PATH directly rather than guessing. Splitting it on ; makes it readable; you are looking for a line ending in \Programs\Ollama. Check that the binary is actually there too — an interrupted install can leave the PATH entry without the files, or the files without the entry.

PowerShell

# PowerShell — is the directory on PATH?
$env:Path -split ';' | Select-String -Pattern "Ollama"

# Is the binary actually where it should be?
Test-Path "$env:LOCALAPPDATA\Programs\Ollama\ollama.exe"
Get-ChildItem "$env:LOCALAPPDATA\Programs\Ollama"

Did it work? Test-Path returning True means the binary exists and the problem is purely PATH. False means the install did not land where you expect — reinstall, or look wherever you pointed /DIR.

Test-Path "$env:LOCALAPPDATA\Programs\Ollama\ollama.exe"

3. Re-add the directory to your user PATH

If the binary exists and the PATH entry does not, add it back through Settings → System → About → Advanced system settings → Environment Variables, editing Path under *User variables for {your account}* — not the System section. The PowerShell equivalent below writes the same user-scoped value. Note that $env:Path = ... on its own only affects the current window; the [Environment]::SetEnvironmentVariable call with the "User" scope is what persists.

⚠️ Read the existing value before you write a new one. Overwriting PATH with just the Ollama directory, rather than appending to it, breaks every other command-line tool on the account.

PowerShell

# PowerShell — append, never overwrite
$old = [Environment]::GetEnvironmentVariable("Path", "User")
$dir = "$env:LOCALAPPDATA\Programs\Ollama"
if ($old -notlike "*$dir*") {
  [Environment]::SetEnvironmentVariable("Path", "$old;$dir", "User")
}

Did it work? Open a new terminal — the change does not reach the current one — and confirm the command resolves.

Get-Command ollama | Select-Object Source

4. Do not run it from an Administrator terminal

This is the one nobody spots. An elevated shell does not run as *you with more rights*; on many configurations it runs under a different account whose user PATH has never seen the Ollama installer. So the command is missing precisely in the window you opened to fix things. Ollama does not need Administrator for anything in normal use — it installs, runs and serves entirely from your own profile. Use a normal terminal.

PowerShell

# PowerShell — which account is this shell actually running as?
[Security.Principal.WindowsIdentity]::GetCurrent().Name
[Environment]::GetEnvironmentVariable("Path", "User") -split ';' | Select-String "Ollama"

Did it work? Run both lines in your normal terminal and in the elevated one. Different account names, or an Ollama entry in one and not the other, confirms the diagnosis.

5. For a service, a scheduled task or CI, install the standalone zip machine-wide

A per-user install is invisible to LocalSystem and to any other account, so it is the wrong shape for anything unattended. Ollama publishes a standalone archive for this: ollama-windows-amd64.zip for NVIDIA and CPU, and ollama-windows-amd64-rocm.zip if you have a Radeon and want the ROCm backend. Unpack it somewhere machine-wide such as C:\Program Files\Ollama and add that directory to the System PATH. Readers hunting this error sometimes turn out to have downloaded the wrong archive for their GPU, which is a different problem wearing the same clothes.

PowerShell

# PowerShell as Administrator — machine-wide, for services and CI only
Expand-Archive .\ollama-windows-amd64.zip -DestinationPath "C:\Program Files\Ollama"
$sys = [Environment]::GetEnvironmentVariable("Path", "Machine")
[Environment]::SetEnvironmentVariable("Path", "$sys;C:\Program Files\Ollama", "Machine")

Did it work? From a brand-new terminal on any account, the command resolves to the Program Files copy.

(Get-Command ollama).Source

6. If you are only trying to run a model, use the app Most common fix

Worth stating before anyone spends an hour on PATH: the desktop app pulls and runs models without a terminal at all. The CLI matters when you want scripting, the API, or a Modelfile — but if you landed here from a tutorial and just want a model answering questions, the tray app is a complete path. Pick a model that fits your hardware and you are running in a couple of minutes.

Check what fits your hardware — pick a model sized for your machine before the first pull
Open the VRAM checker →

If none of this worked

If the command resolves but Ollama then fails to start or serve, the problem has moved past PATH. Two things commonly bite immediately after a successful install on Windows: security software quarantining the binary or the model files, and the API not being reachable from where you are calling it.

Include this when you report it

Output of Test-Path "$env:LOCALAPPDATA\Programs\Ollama\ollama.exe"
The Ollama entry (or its absence) from $env:Path -split ';'
Whether the terminal is elevated, and the account name it reports
How you installed: OllamaSetup.exe, a custom /DIR, or a standalone zip

A model that fits most setups:

View model & requirements →

Frequently asked questions

Where does Ollama install on Windows?

Binaries go to %LOCALAPPDATA%\Programs\Ollama, logs and updates to %LOCALAPPDATA%\Ollama, and models and configuration to %HOMEPATH%\.ollama. The install is per-user and needs no Administrator rights, which is why the PATH entry it adds is user-scoped.

Why does "run as administrator" make it worse?

Because an elevated shell reads a different account's user PATH, and Ollama installed into yours. The command that works in your normal terminal is genuinely absent from the elevated one. Nothing about Ollama needs elevation in normal use.

Do I have to reboot after installing?

No. Closing and reopening the terminal is enough, because a process only reads its environment block at start. Reboot only if you edited PATH and even a fresh terminal does not pick the change up, which usually means the value was written to the wrong scope.

Can I install Ollama somewhere other than my user profile?

Yes. OllamaSetup.exe /DIR="d:\some\location" puts the application elsewhere at install time — useful when C: is small, since the program is a few gigabytes on its own. That is separate from where models are stored, which OLLAMA_MODELS controls.

Which standalone zip do I need?

ollama-windows-amd64.zip covers NVIDIA and CPU. ollama-windows-amd64-rocm.zip adds the AMD ROCm backend for Radeon cards. Downloading the wrong one gives you a working command that then ignores your GPU, which looks like a different problem entirely.