Repository navigation
WinGet install with PortableCommandAlias gives wrong message when installed with non elevated privileges #6058
Description
Relevant area(s)
WinGet CLI
Relevant command(s)
winget install
Brief description of your issue
On a non elevated shell, when installing a package with a PortableCommandAlias in its winget-pkgs manifest, the installer wrongly outputs "Command line alias added: ", which is not true. See: #6043 (comment)
As this did not happen, it should not output this message.
Steps to reproduce
winget install int128.kubelogin
Expected behavior
Found kubelogin [int128.kubelogin] Version 1.35.2
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...
Successfully installed
Actual behavior
Found kubelogin [int128.kubelogin] Version 1.35.2
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...
Command line alias added: "kubectl-oidc_login" #< wrong message
Successfully installed
Environment
[winget --info]
Windows Package Manager v1.28.190
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.22631.6491
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.28.190.0
Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User) %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User) %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root C:\Program Files\WinGet\Packages
Portable Package Root (x86) C:\Program Files (x86)\WinGet\Packages
Installer Downloads %USERPROFILE%\Downloads
Configuration Modules %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules
Links
---------------------------------------------------------------------------
Privacy Statement https://aka.ms/winget-privacy
License Agreement https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale
Admin Setting State
--------------------------------------------------
LocalManifestFiles Enabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride Disabled
LocalArchiveMalwareScanOverride Disabled
ProxyCommandLineOptions Disabled
DefaultProxy Disabled
Activity
denelon commentedon Feb 18, 2026
The package appears to install and launch correctly:
When I extract the .zip directly, the "executable" is named "kubelogin.exe".
The manifest specifies the command line alias "kubectl-oidc_login".
WinGet appears to be working correctly in this case.
tonur commentedon Feb 18, 2026
Are you running this as an administrator?
denelon commentedon Feb 20, 2026
No, I did not run the installer elevated. I did have Developer Mode enabled though.
If the manifest does not specify the requirement to add a path entry WinGet has the following behavior:
If installation is elevated (run as administrator) or Developer Mode is enabled, create a symbolic link.
If not elevated and Developer Mode is not enabled, create a path entry.
In either case when a manifest has a portableCommandAlias that is the "name" of the executable after installation.
The latest entry for kubelogin has such an entry.
tonur commentedon Mar 7, 2026
Demitrius Nelon (@denelon) I don't think I understand what you mean, when you say it will create a path entry.
I cannot replicate what you did in your original comment. This is what happens when I try to install it:
There is no way to call the package with the "portableCommandAlias" name.
Thus, I would classify this
Command line alias added: "<portableCommandAlias>"message as a bug.sysopmd commentedon Mar 12, 2026
Same issue here: non elevated prompt, developer mode off:
Italian-localized: it says both 'path modified' and 'alias added'. However no 'git-flow' alias is available. I understand this is by design but a little confusing for me. Instructions I find just say to install packages not to enable developer mode to get working aliases.
Anyways the message 'alias added' without actually adding it is definitely a bug.
Re-executing after enabling developer mode it works: the alias actually gets added under Links.
rich-purnell commentedon Jun 6, 2026
I encountered the same issue while installing Godot. The log shows symlink creation failure:
I checked
%USERPROFILE%\AppData\Local\Microsoft\WinGet\Links– it was empty, and that directory isn't even in my PATH. So aliases have never worked for me.Compiling winget-cli requires Developer Mode, which prevents reproducing the problem. So I extracted the key code into a small test project. The results show that without admin privileges and Developer Mode,
std::filesystem::create_symlink(target, link);fails with:However,
std::filesystem::create_hard_link(target, link);works fine.My suggestion: try to create a symlink first; if it fails due to permission errors, fall back to a hard link. Hard links should work in most cases.
This won't solve every scenario (e.g., when the Links directory and the Packages directory are on different drives, hard links won't work), but it would reduce the impact for many users.
I've created PR #6270 that implements this approach.