Confusing winget upgrade/list summaries for pinned, explicit-target, and --include-unknown packages

[niStee]

winget upgrade and winget list --upgrade-available show confusing and sometimes self‑contradictory summary messages around pinned packages, packages requiring explicit targeting (RequireExplicitUpgrade), and packages with unknown versions, even when there are no user pins configured and --include-unknown does not change the result set. This overlaps with several existing issues (for example #1939, #4741, #3066, #2559, #2973, #2974, #3263, #5878), but the combined UX is still very misleading for end users.

I have searched existing open and closed issues and PRs before filing this bug and am filing this as a focused UX and behavior report that ties these pieces together.

Steps to reproduce

1. Ensure Chocolatey.Chocolatey is installed and has an update available in the winget source.

   winget install Chocolatey.Chocolatey wait until a newer version is available

2. Run one of:

   winget upgrade --all

   or:

   winget upgrade --all --include-unknown

3. Observe output similar to:

    No installed package found matching input criteria.

    The following packages have an upgrade available, but require explicit targeting for upgrade:
    Name                      Id                    Version Available Source
    ------------------------------------------------------------------------
    Chocolatey (Install Only) Chocolatey.Chocolatey 2.5.0.0 2.5.1.0   winget

    1 package(s) are pinned and need to be explicitly upgraded.
    2 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.

4. Check pins: winget pin list winget pin list --id Chocolatey.Chocolatey

   Both commands report:

   There are no pins configured.

   So at this point, there are no user‑visible pins, but the summary still claims there is a pinned package.

5. Try the suggestion for unknown versions:

   winget list --upgrade-available --include-unknown

   Output:

   No installed package found matching input criteria.

   There are no extra rows corresponding to the X package(s) have version numbers that cannot be determined message.

6. Now explicitly add a pin:

   winget pin add --id Chocolatey.Chocolatey winget upgrade --all

   Now the summary again reports a pinned package, but the wording is identical to what was shown earlier when no user pins existed, so the user cannot tell these states apart from the summary text alone.

Expected behavior

From a user perspective:

1. The X package(s) are pinned and need to be explicitly upgraded summary should only count user‑visible pins, entries shown in winget pin list, or should clearly distinguish between user pins created via winget pin and internal, manifest, or policy blocks such as RequireExplicitUpgrade.

2. The X package(s) have version numbers that cannot be determined. Use --include-unknown to see all results. message should only be shown when there is at least one unknown‑version package that actually maps to a catalog entry and using --include-unknown will cause those packages to appear in the result list.

3. When no packages are eligible for automatic upgrade but some require explicit targeting, the main message should reflect that, for example No packages matched for automatic upgrade. Some packages require explicit targeting for upgrade and are listed below. instead of stating No installed package found matching input criteria. directly above a list of upgradeable packages.

In short, the summary should align with what the user can see and control via the public commands, upgrade, list, pin, and should not suggest actions that result in no visible change.

Actual behavior

• Before any user pins are configured, winget upgrade --all can print No installed package found matching input criteria. followed by a section listing packages that have an upgrade available, but require explicit targeting for upgrade and a summary saying that 1 package(s) are pinned and need to be explicitly upgraded even though winget pin list reports There are no pins configured.

• The X package(s) have version numbers that cannot be determined. Use --include-unknown to see all results. summary appears, but winget upgrade --all --include-unknown shows no additional rows and winget list --upgrade-available --include-unknown still reports No installed package found matching input criteria. with no entries corresponding to those unknown‑version packages.

• After explicitly pinning Chocolatey.Chocolatey, the summary line about a pinned package becomes literally correct, but the text is identical to the earlier state with zero user pins, so there is no way for users to distinguish between a real pin they created and can manage via winget pin and internal constraints that behave like pins but do not show up in winget pin list.

Environment

[winget --info]

Windows Package Manager version: Windows Package Manager v1.12.350  
Windows: Windows.Desktop v10.0.26100.7171  
System Architecture: X64  
Package: Microsoft.DesktopAppInstaller v1.27.350.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

Admin Setting State.

LocalManifestFiles: Disabled  
BypassCertificatePinningForMicrosoftStore: Disabled  
InstallerHashOverride: Disabled  
LocalArchiveMalwareScanOverride: Disabled  
ProxyCommandLineOptions: Disabled  
DefaultProxy: Disabled

Additional context.

• Chocolatey.Chocolatey installed via winget with an update available.
• No custom winget settings related to pins or sources, other than the commands shown above.
• This is not a security or BSOD issue, and I am not attaching memory dumps or other sensitive diagnostics; this is a behavioral and UX bug report per the project’s SUPPORT and SECURITY guidelines.

[Trenly]

The issue with unknown count is known and should be addressed whenever a fix is put in for #2458.

[eabase]

How do you check the mentioned policy block, RequireExplicitUpgrade for a package? (I would like to check for #5878.)

[niStee]

How do you check the mentioned policy block, RequireExplicitUpgrade for a package? (I would like to check for #5878.)

As to my knowledge, right now there is no winget CLI flag that shows the RequireExplicitUpgrade flag for a package. To check it, you have to look at the manifest in the microsoft/winget-pkgs repo: navigate to manifests/<F>/<Publisher>/<PackageId>/<Version>/ and open the .yaml file, then look for RequireExplicitUpgrade: true (and related fields like UpgradeBehavior). For the package in #5878, the explicitly‑targeted one is MSYS2.MSYS2, and its manifest has been configured by the maintainers with an upgrade behavior of “deny” and “requires explicit upgrade”, which is, as I understand it, why it appears in the separate “require explicit targeting” section and is skipped by bulk upgrade. See https://github.com/microsoft/winget-pkgs/issues/127282#issuecomment-2576329852 and manifests/m/MSYS2/MSYS2/20250830/MSYS2.MSYS2.installer.yaml

[denelon]

I agree the UX is confusing in this case.

The concepts around "unknown" version, pinned packages, and packages with an explicit upgrade required (based solely on the manifest) are not surfaced fully in the client. This is a great call out.