Azure Pipelines · agents · Checked November 6, 2026

Azure Pipelines: "Unable to locate executable file: 'pwsh'"

Before a task runs pwsh, bash, powershell, az or another tool, it looks for that file in the folders of the agent's PATH. When none has it, the task stops with this message (from the task library, which every task uses). The name in quotes is the file it looked for; the fix is to make that file exist on the agent, or to ask for one that does (questions on Stack Overflow with this message have been seen over 260,000 times).

When the failing step is part of a pull request's build validation, the pull request waits on it: Azure DevOps Pull Requests, a plugin for JetBrains IDEs, lists the pull request's branch policies with their state in your IDE, and with Pro runs a failed build policy again once the agent is fixed. Get it on JetBrains Marketplace

What it looks like

• ##[error]Unable to locate executable file: 'pwsh'. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. On Linux and macOS it goes on to say to check that the file is executable; on Windows, that it has an extension for an executable file.
• The name changes with the task: pwsh for PowerShell 7 (pwsh: true, or scriptType: pscore), powershell for Windows PowerShell, bash for the Bash task, az for the Azure CLI task.

'powershell' on a Linux agent

• Windows PowerShell (powershell) exists only on Windows. On ubuntu-latest or any Linux agent, AzureCLI@2 with scriptType: ps asks for it and fails.
• Use scriptType: pscore (PowerShell 7) or scriptType: bash. The task's own help says the same: Shell or PowerShell Core on Linux, Batch, PowerShell or PowerShell Core on Windows (the most voted answer on a question about it).

The tool is not installed on a self-hosted agent

• Microsoft-hosted images come with PowerShell 7, bash and the Azure CLI. A self-hosted agent has only what someone installed on that machine. For 'pwsh' on Linux, install PowerShell from Microsoft's package repository (answers on the most read question); for 'az' on Windows, install the Azure CLI with its MSI on the agent machine, once, instead of in every run.
• 'bash' on a Windows agent: the Bash task needs a bash.exe on PATH, usually the one from Git for Windows. If the script is really PowerShell, use a PowerShell task instead (another answer).
• After installing, restart the agent, or its service, so that it starts with the new PATH.
• A tool installed in a step of the same job is on disk but not on PATH for the next steps. Print ##vso[task.prependpath]C:\Program Files\Microsoft SDKs\Azure\CLI2\wbin (with your folder) from a script step, and later steps get that folder in front of PATH (Microsoft's logging commands).

A pipeline variable named path

• Every variable that is not secret is also given to the steps as an environment variable, with its name in capitals (Microsoft's page on variables). A variable called path, for a file or folder in your build, becomes PATH and replaces the agent's. After that, no tool can be found, even one that is clearly installed.
• Rename it, for example to projectPath (an answer on the 'bash' question that fixed it this way).

The agent service does not see your PATH

• Run as a service, the agent uses the account the service runs as, and on Windows the system PATH plus that account's own. A tool installed only for your user, or with PATH changed only in your shell profile, is not there. Install it for all users, or add its folder to the system PATH, and restart the service.
• To see what the agent sees, add a step that prints it: - script: echo $PATH on Linux and macOS, - powershell: $env:PATH on Windows. Compare that with the folder the tool is in.

Azure DevOps pull requests in IntelliJ IDEA and Rider

Azure DevOps Pull Requests, a plugin by Lesstep for JetBrains IDEs 2024.1 or later and Android Studio, reads the organization, project and repository from your git remote and lists the pull requests that wait for your review in an IDE tool window, on Azure DevOps Services and on Azure DevOps Server. It shows the branch policies of a pull request with their state, so a required build that has not passed is next to its pull request, and with Pro you run a failed or expired build policy again from there. The review inbox is free; voting, commenting, completing and creating are Pro, with a 30-day trial.

Get it on JetBrains Marketplace

Azure DevOps, Azure Pipelines and PowerShell are trademarks of Microsoft Corporation; IntelliJ IDEA and Rider are trademarks of JetBrains s.r.o. This page is not affiliated with or endorsed by Microsoft or JetBrains.

More: no agent satisfies the demands · checkout stops with Git fetch failed with exit code: 128 · the dotnet task matched no project · 日本語