microsoft / microsoft/winget-cli

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

Open
#5,879 4 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Area-User-Interface Issue-Feature
Dominant language
C++
Stars
26.4k
Forks
1.8k
Avg merge
1d 11h
Merged PRs (30d)
15

Description

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.
  1. 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.

  2. 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.

  3. 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the reported behavior with winget upgrade --all, winget upgrade --all --include-unknown, winget list --upgrade-available --include-unknown, and the winget pin commands. Trace how upgrade and list summaries classify pinned, explicitly targeted, and unknown-version packages. Done means the summaries match visible results and distinguish user pins from internal constraints.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
cli
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.