The *.appxbundle installer does not automatically add the installation directory for winget.exe to the PATH environment variable in Windows 10

[jwheeler88]

Brief description of your issue

When installing winget via the *.appxbundle installer, the installation directory for winget.exe is not automatically added by the installer to the PATH environment variable; this should have been added automatically so that the CLI commands can work out of the box.

Steps to reproduce

1. Install winget from the v0.1.4331-preview release, using the *.appxbundle installer.
2. View the systems PATH environment variable to confirm whether the installation folder for winget was added.

Expected behavior

The installation folder for winget is added to the system PATH environment variable.

Actual behavior

The installation folder for winget is not added to the system PATH environment variable.

Environment

[winget --info]
Windows Package Manager v0.1.41331 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.18362.778
Package: Microsoft.DesktopAppInstaller v1.0.41331.0

Any other software?

[LuanVSO]

winget uses an "execution alias" to add itself to path. it should be in
C:\users\<username>\AppData\Local\Microsoft\WindowsApps
if it is enabled in windows settings->aplications->app execution alises

[aslze]

I just installed the appxbundle and I could not immediately run winget even spawning a new console. I thought it was not added to the PATH. I had to log out and log in for it to work.

[jwheeler88]

winget uses an "execution alias" to add itself to path. it should be in C:\Users%userprofile%\AppData\Local\Microsoft\WindowsApps
if it is enabled in windows settings->aplications->app execution alises

It did seem to activate it's alias correctly, but yet it still did not add to the PATH variable--however @aslze mentions he needed to log out and back in for it to work.

I just installed the appxbundle and I could not immediately run winget even spawning a new console. I thought it was not added to the PATH. I had to log out and log in for it to work.

[davefollett]

I seemingly had the same or similar PATH problem. I installed winget by joining the "Microsoft Package Manager Insiders Program" and installing through the Windows Store.

I installed winget.exe from the Windows Store as a standard user, Dave, and winget.exe was installed to: "C:\Users\Dave\AppData\Local\Microsoft\WindowsApps\winget.exe".

When trying to run winget, I got an executable not found error. Looking at the PATH environment variable, I did have "C:\Users\Admin\AppData\Local\Microsoft\WindowsApp" set for the administrator account not for the Dave user or system wide. I also had the execution alias as mentioned above and logging out/in nor a reboot fixed things.

In order to make it work I had to add this to my system environment variable for PATH:

%userprofile%\AppData\Local\Microsoft\WindowsApps

As shown in this screenshot:

UPDATED: Added operating system Info

Windows 10 Pro (not insiders)
Version: 1909
Build: 18363.836

[JHentges]

I installed via the via the *.appxbundle installer a few minutes ago and was able to open a CMD and "winget show firefox" immediately: no problem found. I am logged into Windows as an administrator, in case that's pertinent.

[M2vH]

This MUST be part of your $PATH variable:

%userprofile%\AppData\Local\Microsoft\WindowsApps

without the above in $PATH NONE of the Apps installed in WindowsApps can be executed from shell.

Don't know, if the above directory is part of $PATH by default?

[MisinformedDNA]

My path is set correctly, but the alias didn't get setup.

Is there a way to manually add it? Or something else I can try?

[b3n-h4il]

Well, i do have the correct PATH setup for the Windows Apps folder. But inside of it there isn't a Winget.exe file, so i get the same error with the winget command. I don't have a Windows Insider Build, used the link to use the App Installer through the Windows Store. I reseted the App Installer app in the configurations, then tried to install it again. But there in't any alias for Winget.exe nor an executable file. Any ideas?

[MisinformedDNA]

I joined the "Microsoft Package Manager Insiders Program", but it looks like I'm not getting the latest version:

Hmmm... I just noticed something. The project readme file says "Windows 10 1709 (build 16299) or later" and the email says "Windows 10, version 1809 (or later)". Which one is it?

[b3n-h4il]

I joined the "Microsoft Package Manager Insiders Program", but it looks like I'm not getting the latest version:

Hmmm... I just noticed something. The project readme file says "Windows 10 1709 (build 16299) or later" and the email says "Windows 10, version 1809 (or later)". Which one is it?

I'm having the same issue, and i used the same installation method. I couldn't notice any change in the Installation App.

[MisinformedDNA]

BTW: I'm on v1803. (Need to get IT to upgrade me.)

[Pentao]

Having the same issue here,
I'm on version 1903.
The app store confirms that the product is installed.
I restarted the machine, but not App execution alias is added for winget.
Winget is not in my path:
%userprofile%\AppData\Local\Microsoft\WindowsApps

[nirinsanity]

I've the same issue the last four people above me have been facing.

[Amir-Abushanab]

Same as the above, I installed through the App Store and restarted my machine (build 19041), and confirmed that %USERPROFILE%\AppData\Local\Microsoft\WindowsApps is in my PATH too.

However, winget is not recognized as a command (running from PS 7 if that makes any difference)

[alexmacniven]

Having the same issue here,
I'm on version 1903.
The app store confirms that the product is installed.
I restarted the machine, but not App execution alias is added for winget.
Winget is not in my path:
%userprofile%\AppData\Local\Microsoft\WindowsApps

I'm experiencing this too after signing up to the Windows Package Manager Insiders Program and attempted to download and install from the store.

[timmyb824]

@alexmacniven I had the exact same issue. I went to https://github.com/microsoft/winget-cli/releases and ran the appxbundle asset at the bottom and that updated my app installer. Winget works now. I think the only issue with doing it this way is that it will no longer update automatically. But at least it works now.

[Chimera99]

After updating manually, Winget did not work. The solution that worked for me was to add an absolute address path to the enviromental variable of PATH C:\Users\%USERPROFILE%\AppData\Local\Microsoft\WindowsApps in addition to what was already there %USERPROFILE%\AppData\Local\Microsoft\WindowsApps , then log out and log back in to resolve issue.

Following the instructions from the automated email did not work, the manual install has a better success rate overall after installing on three machines.

[Pentao]

@alexmacniven I had the exact same issue. I went to https://github.com/microsoft/winget-cli/releases and ran the appxbundle asset at the bottom and that updated my app installer. Winget works now. I think the only issue with doing it this way is that it will no longer update automatically. But at least it works now.

==
Followed this steps, and it works.
I tried winget install powertoys, it installs but, it is disappointing that I get a GUI prompt to continue, is there a way to escape this? Kinds of defeats the purpose of the tool, isn't it?

[MisinformedDNA]

@Pentao Try running the shell in administrative mode.

[steveklabnik]

I ran into this today on a brand new machine and install. Rebooting (which logs me out, of course, like some folks have suggested above) made it work for me.

[ermshiperete]

I don't think #235 is an exact duplicate. The focus of that issue is on the misleading and confusing message.

[kevsterd]

@alexmacniven I had the exact same issue. I went to https://github.com/microsoft/winget-cli/releases and ran the appxbundle asset at the bottom and that updated my app installer. Winget works now. I think the only issue with doing it this way is that it will no longer update automatically. But at least it works now.

Had the same on W10 2004 Build.19401 today. As above, installed the App Installer package from store then pulled latest version from GH....

[diablodale]

windows terminal is experiencing the same problem. They identified it as the store/centennial/appx install process for appexecutionalias is not fully specifying the path to the aliases and instead using a path with embedded %USERPROFILE%. However that fails because the PATH environment variable in the registry is REG_SZ and not REG_EXPAND_SZ. Therefore that variable reference is not expanded.

Can someone at Microsoft escalate this shared issue to the Microsoft team(s) responsible for that area?

[zooba]

Windows adds the PATH entry itself - it's part of your default user profile, and nothing to do with any particular APPX installer or even the Store. Changing from REG_EXPAND_SZ back to REG_SZ will be due to a third-party installer. I've been tracking issues like this for a while, as they affect the Centennial package of Python.

We've already fixed a few issues relating to apps disabling or resetting their aliases on package update, and also fixed a regression in a security patch late last year. The first couple of issues could have been either of those (though if you've got WinGet you should be on an insider build with fixes for those... so I'm still leaning towards third-party installer).

Most of the reports in this thread seem to be people who are not getting the preview build of App Installer. Unfortunately, it's not real obvious how to make sure you have the preview version here. Running Get-AppxPackage Microsoft.DesktopAppInstaller in PowerShell will show the current package version though (I don't know the right one myself, but a few contributions should show a pattern fairly quick).

[diablodale]

Naturally, anything with write access (has nothing to do with an installer) to HKEY_CURRENT_USER\Environment key and value Path can change it from REG_EXPAND_SZ to REG_SZ.

I think it is reasonable for the infrastructure (Microsoft Store + Windows) to correctly check/set/install all needed dependencies when an app is installed via that store. Therefore...

1. Since app aliases are part of the app's install
2. App alias functionality depends on PATH being correctly configured to %USERPROFILE%\AppData\Local\Microsoft\WindowsApps

That would require the dependency of app aliases to do at a minimum

1. make the alias in %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
2. ensure the PATH includes %USERPROFILE%\AppData\Local\Microsoft\WindowsApps
3. ensure the PATH is REG_EXPAND_SZ. When it is only REG_SZ, then do the needed re/write of path back to REG_EXPAND_SZ

Seems to me the dependency handing of (Microsoft Store + Windows) is not doing steps 2 and 3.
If the dependency handling is updated then it allows much...

1. Bugs due to the PATH reg key not being REG_EXPAND_SZ go away
2. When something else changes REG_EXPAND_SZ to REG_SZ at any time, then one or more aliases will fail. However, then the user can use the standard Windows App->Repair/Reset. Since the improved dependency handling will include steps 2 and 3 above...and therefore fix the registry key back to REG_EXPAND_SZ

[zooba]

The Python redirector is in the AppInstaller package along with winget because it was a sensible place to put it, that's all. It's unrelated to (and predates) Winget.

As for the install location, all the application files go into ProgramFiles, but there's still a bit of per-user registration that makes it look like a per-user install. That gives each user their own "view" of it, even though the entire install is shared (and secured).

This particular package should be automatically installed for all users though, so you ought to have Winget as admin. However, I'm guessing the global alias is not being created for users who are not logged in (I'm not 100% sure how that bit gets handled, but some of the Winget team are close enough to the right people to find out).

[Kein]

Does anyone know how to add alias manually into %USERPROFILE%\AppData\Local\Microsoft\WindowsApps\ ? It does look like your basic soft symlink but it isnt, it some kind of hybrid between shortcut and symlink because it respects the startup path so naturally, creating just symlink for AppInstallerCLI.exe does nothing and creating basic windows shortcut/LNK also wont work, obviously.

[denelon]

We are working on isolating this problem. It appears to be related to either Windows 10 and/or App Execution Aliases. I'm adding the area-external label to help remind us to follow up internally until we are able to find a resolution.

[denelon]

@jwheeler88 we've updated our troubleshooting guide. Let us know if this doesn't resolve the issue.

[Sparx2]

winget uses an "execution alias" to add itself to path. it should be in C:\users<username>\AppData\Local\Microsoft\WindowsApps if it is enabled in windows settings->aplications->app execution alises

Oh, my mind ! Its a my computer and profile and I can't login .I am a bit angry

[Masamune3210]

I think you are confused, a execution alias is basically a shortcut to a program, a alias is another word for nickname or alternate name. They weren't referring to you by name

[argha2000]

After updating manually, Winget did not work. The solution that worked for me was to add an absolute address path to the enviromental variable of PATH C:\Users\%USERPROFILE%\AppData\Local\Microsoft\WindowsApps in addition to what was already there %USERPROFILE%\AppData\Local\Microsoft\WindowsApps , then log out and log back in to resolve issue.

Following the instructions from the automated email did not work, the manual install has a better success rate overall after installing on three machines.

I was facing the same issue for the last 1 month. Following these steps worked for me

[kaerez]

Issue still alive and well. How long does it take to fix the path? This is a store wide issue.

[botsama]

I just installed the appxbundle and I could not immediately run winget even spawning a new console. I thought it was not added to the PATH. I had to log out and log in for it to work.

Thank you for this tip. Just had an issue trying to use kubeconfirm that I installed with winget and it did not see binary when I opened a new cmd console, but logging out and back in has the path sorted now.

Adding OS for context:
OS Name: Microsoft Windows 11 Pro
OS Version: 10.0.22621 N/A Build 22621

[storrer]

After updating manually, Winget did not work. The solution that worked for me was to add an absolute address path to the enviromental variable of PATH C:\Users\%USERPROFILE%\AppData\Local\Microsoft\WindowsApps in addition to what was already there %USERPROFILE%\AppData\Local\Microsoft\WindowsApps , then log out and log back in to resolve issue.
Following the instructions from the automated email did not work, the manual install has a better success rate overall after installing on three machines.

I was facing the same issue for the last 1 month. Following these steps worked for me

This worked for me on Windows 11 in August 2023.

[supermario-ai]

USERENV = WINGET=%LOCALAPPDATA%\Microsoft\WindowsApps
SYSENV=Path > Edit > %WINGET%
❤️💯