`winget list` and `upgrade` do not match installed packages to available packages in configured sources

Brief description of your issue

Description

winget list, if called without arguments for the query parameter, fails to match an installed package with its available package from a configured source. When an installed package fails to match to an available package from a configured source, the Package ID will look like “ARP\Machine\X64...”. However, running winget list <search_term> does result in the installed package matching with its appropriate available package, even if the search term is as simple as a singular letter present in the package’s ID or Name.

For example, we have Git.Git version 2.48.1 available in our private repository. We only maintain one version in our private repository and remove old versions when new versions are published. If you were to have installed Git version 2.46.0 either manually or in the past from the same private source, a simple winget list will fail to match the packages. However, winget list g will return several installed packages, including Git.Git, and match the packages properly.

Similarly, winget upgrade will fail to match packages and identify an available upgrade. However, if you run winget upgrade <search_term>, then the packages will match appropriately so long as the desired package appears in the results.

Once you’ve installed the latest version of a package from the configured source, WinGet subsequently matches packages successfully.

I've confirmed this affects Git.Git and Notepad++.Notepad++, but Microsoft.PowerShell seems to not respond to the proposed workaround.

Steps to reproduce

Environment Details

Windows 11 or Windows Server 2025

WinGet Client version 1.9.25200 (latest stable), and 1.8.1911

Private self-hosted WinGet source configured (default sources removed)

Steps

Manually install a package that is available from a configured source.

Run winget search <query> to find the package in question and confirm it is available in the configured source.

Run winget list and winget upgrade (if the installed version is older than the available version), taking note of the results

Expected behavior

winget list should show all installed packages the WinGet Client can identify, including the package we’ve installed manually, with the Package ID and Package Name aligning with what is available in the configured source

winget upgrade should detect an upgrade is available to the package in question, assuming a version older than the one available in the configured source is installed

Actual behavior

winget list fails to match installed packages with available packages, showing a Package ID pulled from the registry

winget upgrade fails to detect an available upgrade for the package in question

Environment

Windows Package Manager v1.9.25200
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22631.4317
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.24.25200.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

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                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

Start with the winget list and winget upgrade command entry points, then trace how installed ARP entries are matched against results from the configured source; compare that path with query-bearing invocations and winget search. Done means manually installed packages match their source Package ID and name in list, and older versions are detected by upgrade without requiring a search term.