WinGet install with PortableCommandAlias gives wrong message when installed with non elevated privileges

[tonur]

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

[denelon]

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]

Are you running this as an administrator?

[denelon]

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]

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]

Same issue here: non elevated prompt, developer mode off:

Questa applicazione viene concessa in licenza dal proprietario.
Microsoft non è responsabile né concede alcuna licenza a pacchetti di terze parti.
Download in corso https://github.com/gittower/git-flow-next/releases/download/v0.1.1/git-flow-next-v0.1.1-windows-amd64.zip
  ██████████████████████████████  2.50 MB / 2.50 MB
Verifica dell'hash di installazione completata
Estrazione del file compresso
Estrazione del file compresso completata con successo.
Avvio installazione pacchetto in corso...
Variabile di ambiente del percorso modificata; riavviare la shell per usare il nuovo valore.
Alias della riga di comando aggiunto: "git-flow"
Installazione riuscita

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]

I encountered the same issue while installing Godot. The log shows symlink creation failure:

2026-06-06 03:00:27.318 [CORE] Failed to create symlink at: C:\Users\richj\AppData\Local\Microsoft\WinGet\Links\godot.exe

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:

Error code: 1314 - create_symlink: A required privilege is not held by the client.

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.