Added a Tool to PATH? Why Your Terminal Still Can’t Find It

You install a command-line tool, add its folder to PATH, and try it in PowerShell. PowerShell still says the command is not recognised. Reinstalling the tool is tempting, but first check which PATH that session is actually using.

A saved PATH edit and an already-running program’s environment are separate things. The edit can be correct while an open shell still has an older value. A different problem can produce a similar symptom: the wrong folder was added, another executable wins the search, or PowerShell resolves an alias instead.

Compare three things: the file on disk, the PATH in the failing session, and the command PowerShell finds. That tells you whether to refresh the session, correct the saved entry or investigate a name conflict.

The commands below use Windows PowerShell 5.1. tool.exe and C:\Tools\Example\bin are illustrative names; replace them with your tool’s executable name and actual installation folder.

Why a saved PATH change can miss an open shell

PATH is a list of directories used to find executable commands. On Windows, semicolons separate the entries. PowerShell exposes the current process’s value as $env:Path.

There are three relevant scopes:

Microsoft’s PowerShell environment-variable documentation explains these scopes and distinguishes changes in a session from persistent User or Machine settings.

When a program starts another program, the new child process normally inherits a copy of its parent’s environment. Windows also lets the parent supply a different environment explicitly. Those are the rules in Microsoft’s process-environment documentation.

Suppose PowerShell starts before an installer adds a directory to your saved PATH. That open PowerShell process can keep its earlier copy. Starting another powershell.exe from inside it normally passes that copy along. A new process does not automatically mean a newly assembled environment.

Applications can respond to environment-change notifications or deliberately rebuild the environment they give to a child. That is why the useful question is what the failing shell contains, rather than how recently its window or tab appeared.

1. Confirm the executable exists

Find the installation folder using the publisher’s instructions or the installer’s chosen location. If the executable is C:\Tools\Example\bin\tool.exe, the directory you need is C:\Tools\Example\bin. Adding C:\Tools\Example will not make a search descend into its bin subfolder.

You can check the specific file without launching it:

Test-Path -LiteralPath 'C:\Tools\Example\bin\tool.exe' -PathType Leaf

True means that path resolves to a file. False means this check did not find a file there; it does not tell you whether the tool exists somewhere else. Investigate an error message separately. Microsoft’s Test-Path reference documents both the literal-path parameter and the file-type check.

Confirm the filename too. The name of a downloaded installer may be different from the command it installs. PATH cannot fix an incorrect command name or a file that was never installed.

2. Compare this session with the saved settings

Run these commands in the PowerShell session where the command fails. They display the current process value and the two saved Windows values, with one PATH entry per line:

# This PowerShell process
$env:Path -split ';'

# Saved settings for your Windows account
[Environment]::GetEnvironmentVariable('Path', 'User') -split ';'

# Saved settings for the computer
[Environment]::GetEnvironmentVariable('Path', 'Machine') -split ';'

The .NET GetEnvironmentVariable method supports selecting the current process, current-user registry settings or local-machine registry settings. These calls read the values; they do not change them.

Look for the directory you confirmed in the first step. Do not expect the three entire lists to be identical. The process has a combined working environment, and its launcher or startup configuration can make further changes.

This comparison narrows the problem before you edit anything. It also avoids adding the same directory repeatedly when the saved entry was already correct.

3. Refresh the session without assuming every host behaves alike

Save your work, open a fresh PowerShell session from Start, and repeat the current-PATH check. If it contains the directory and the old session does not, you have evidence that the difference lies in the sessions’ environments.

A new terminal tab can be enough when the terminal host rebuilds its environment. It can also inherit values supplied by an existing process. Windows Terminal’s launch-options reference distinguishes inherited and fresh environment blocks. Inspect $env:Path in the session you intend to use instead of assuming a new tab has refreshed it.

VS Code adds another detail. Its terminal documentation says later instances can inherit the first running instance’s environment. It also describes restored terminals that reconnect to an existing process or revive a process using its original environment.

If PATH works in a fresh standalone shell but fails inside VS Code, save your files and finish or stop any terminal jobs you need to preserve. Use the terminal tab’s Trash Can button to remove the old terminal instance, then fully exit all VS Code windows. Reopen VS Code from Start and create a new integrated terminal. Then compare again. Continuing a restored terminal may preserve the very environment you are trying to replace.

If a fresh session still lacks the directory, check that you edited the intended Windows account’s settings. Also inspect any shell profile or terminal configuration that changes PATH. Restarting the same configuration repeatedly will not correct a wrong entry or a startup script that overwrites it.

4. Ask PowerShell which command it resolves

A successful search can still select the wrong executable. Check your real command name:

Get-Command tool.exe -All -CommandType Application |
    Select-Object Name, Path

Microsoft’s Get-Command reference documents -All for showing matching commands in execution-precedence order. -CommandType Application limits this check to external executable files. Inspect the returned paths; do not assume the copy you installed most recently is the one being selected.

For the exact name you normally type, you can also include other command types:

Get-Command tool -All |
    Select-Object CommandType, Name, Definition

Among commands already loaded in a session, PowerShell gives aliases, functions and cmdlets precedence over external executables. Microsoft’s command-precedence guide explains the order and the distinction between loaded commands and module discovery. If a same-named function is taking priority, adding another directory to PATH will not remove that conflict.

Why where.exe can give a different answer

For another view of matching files, use:

where.exe tool.exe

Include .exe: in PowerShell, where is normally an alias for Where-Object. Microsoft’s where documentation says the executable searches the current directory as well as PATH by default. It does not report PowerShell’s aliases and functions.

That current-directory search matters. PowerShell does not search the current directory for a bare executable name unless that directory is also on PATH. Use an explicit path such as .\tool.exe when you intend to run that local file. Consequently, finding a file with where.exe is not proof that a bare command name will resolve the same way in PowerShell.

5. Make a focused PATH correction

If the saved entry is wrong or missing, open Environment Variables from Advanced system settings. For a tool that only your account needs, edit Path under User variables. Add the directory that contains the executable, keeping the existing entries. Use the System setting only when an all-user change is intended and you have permission to make it.

Record the previous entry before changing or removing it. Do not replace the entire PATH with one tool’s folder. After saving, start a suitable fresh session and repeat Get-Command to confirm the selected path.

If two versions exist, resolve that deliberately. Check which installation belongs to the project or workflow you are using, then adjust the relevant entry or use the intended executable’s full path. Deleting a directory simply because it appears earlier in a list can break another workflow.

Avoid the setx PATH quick fix

Microsoft’s setx reference documents three traps relevant here: changes apply to future command windows, variable references are expanded, and assignments longer than 1,024 characters are cropped. Rewriting a long PATH through setx can therefore lose entries while still leaving the current shell unchanged.

There is another reason to keep the scopes separate: the current process PATH can already contain Machine entries and launcher-specific additions. Copying that whole value into the saved User PATH can preserve things you did not intend to save. Edit the intended entry at the intended scope instead.

A temporary test, with an explicit undo

If you have confirmed the executable and trust its directory, you can temporarily prepend that directory in the current PowerShell session and inspect resolution. This changes search precedence, so use the exact intended folder. It does not save a User or Machine PATH change.

$jitsumiPreviousPath = $env:Path
try {
    $env:Path = 'C:\Tools\Example\bin;' + $env:Path
    Get-Command tool.exe -All -CommandType Application |
        Select-Object Name, Path
}
finally {
    $env:Path = $jitsumiPreviousPath
}

The finally block restores this session’s previous value after the check. The example asks PowerShell to locate the application; it does not run tool.exe. Microsoft documents the underlying session environment-variable behaviour.

If the expected file now appears, the temporary change has helped isolate a search-path or precedence issue. You still need to decide whether the durable fix belongs in the saved User PATH, the application’s launcher or a project-specific setup.

Finish by checking the resolved executable path in a fresh session. Once PowerShell finds the intended file, a later error about permissions, dependencies or the program’s own configuration is a different problem. PATH troubleshooting is complete when command discovery selects the file you meant to use.