
Path not updated when installing with Winget in Powershell
- 2026-05-30
- 4 minutes to read
Table of Contents
Introduction
Whilst I predominantly use MacOS, I do have to run a Windows VM for certain apps (cough Power BI cough). I ran into an issue recently when trying to installing apps on a vanilla Windows 10 build using Winget via the terminal in VS Code.
After installing the app, I found that the PATH environment variable was not updated, which meant I couldn’t run the app from the command line without specifying the full path. The TL;DR is that Powershell wasn’t up to date - updating to Powershell Core resolved the issue. Here’s a breakdown of what I found and how I resolved it.
PATH
The PATH environment variable is a system variable that tells the operating system where to look for executable files when you run a command in the terminal. When you install an app, it should ideally update the PATH variable so that you can run the app from anywhere in the terminal without having to specify the full path to the executable.
You can see what is currently in your PATH variable by running the following command in Powershell:
echo $env:PATH
You can amend the PATH variable manually, by running the following command in Powershell:
[Environment]::SetEnvironmentVariable("PATH", $env:PATH + ";C:\Path\To\App", 'User')
This will append the new path to the existing PATH variable for the current user. It is important to include the semicolon (;) before the new path to separate it from the existing paths.
You can also manage variables by opening the System Properties, going to the “Advanced” tab, and clicking on “Environment Variables”. From there, you can edit the PATH variable for the user or system.
None of this is ideal though, so why wasn’t the PATH variable updated when I installed the app using Winget?
Winget doesn’t update PATH
By default Winget does not update the PATH environment variable when installing applications. This is because Winget focuses on installing applications and managing their versions, rather than modifying system environment variables.
What appears to be happenening is that Powershell should allow for the update of the PATH variable during the install process, but this does not seem to work in earlier versions of Powershell (and effectively the default version running on a vanilla Windows 10 build). You can check your Powershell version by running the following command:
PS > $PSVersionTable
Name Value
---- -----
PSVersion 5.1.19041.6456
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.19041.6456
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
Powershell Core
Moving to Powershell Core (or if you are already using Powershell Core, make sure you are using the latest version) resolved this issue. When running the same install command in Powershell Core, the PATH variable is updated correctly and I can run the app from the command line without any issues.
I added the Powershell extension to VS Code and switched the default terminal to Powershell Core. I then ran the same install command and this time the PATH variable was updated correctly.
PS > winget install Databricks.DatabricksCLI
Found DatabricksCLI [Databricks.DatabricksCLI] Version 1.1.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Extracting archive...
Successfully extracted archive
Starting package install...
Path environment variable modified; restart your shell to use the new value.
Command line alias added: "databricks"
Successfully installed
Wrapping Up
I have hit this issue at a few client sites, so when I hit this on my local machine I thought I would dig into it a bit more. Ultimately, running the latest version of Powershell Core resolved the issue and I can now install apps using Winget without having to worry about the PATH variable not being updated. Link below to the initial Github issue that led to me working through this issue.
References
#mtfbwy
Comments