Skip to content
Latchkey

PowerShell "is not recognized as the name of a cmdlet" in CI

PowerShell could not resolve the name you invoked to any cmdlet, function, script, alias, or executable. On a CI runner the module that defines the cmdlet is usually not installed or not imported.

What this error means

The step stops with a CommandNotFoundException naming the term. It is deterministic: the same command fails every run because the command simply is not on the session command table.

powershell
Get-FooBar : The term 'Get-FooBar' 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.
At line:1 char:1
+ Get-FooBar
+ ~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (Get-FooBar:String) [], CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException

Common causes

The module that exports the cmdlet is not installed

Cmdlets like Az.*, AWS.Tools.*, or Pester live in modules that must be installed from the gallery. A fresh runner has only the built-in modules, so anything else is unrecognized until you install it.

The module is installed but not imported

Auto-loading only finds modules on PSModulePath. A module installed to a custom location, or one whose manifest does not match, will not auto-load and must be imported explicitly.

A typo or a non-PowerShell command

A misspelled cmdlet, or a Bash-ism (such as which or export) typed into a PowerShell step, resolves to nothing because PowerShell has no such command.

How to fix it

Install the module that provides the cmdlet

Install from the PowerShell Gallery into the current user scope so the step does not need elevation.

powershell
Install-Module -Name Pester -Scope CurrentUser -Force -SkipPublisherCheck
Import-Module Pester
Invoke-Pester

Confirm the command is actually available

Check whether the name resolves at all and which module owns it before assuming it is missing.

powershell
Get-Command Get-FooBar -ErrorAction SilentlyContinue
Get-Module -ListAvailable | Where-Object Name -like '*Foo*'

Use the correct command for the shell

  1. In a PowerShell step, use PowerShell equivalents: Get-Command instead of which, $env:PATH instead of $PATH.
  2. If you need POSIX tools, set the step shell to bash explicitly with shell: bash.
  3. Do not mix Bash syntax into a default Windows step, which runs in PowerShell.

How to prevent it

  • Install required modules in an early setup step and pin their versions, then verify with Get-Command before the step that uses them.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →