[Bug]: The "Winget-AutoUpdate" system-context task fails to recognise changes made to configured sources.

The problem

For reasons I haven't been able to pinpoint despite trying many things (https://github.com/Romanitho/Winget-AutoUpdate/issues/1182#issuecomment-5669758530), running the Winget-AutoUpdate task in system context only ever acknowledges 3 sources: msstore, winget, and winget-font. The result is that setting winget-extras as the source in Winget-Upgrade.ps1 will fail in system context, but will oddly work when running the Winget-AutoUpdate-UserContext task instead.

Checking the log data (as can be seen further below), then on paper it should work to run & 'C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.30.100.0_x64__8wekyb3d8bbwe\winget.exe' source add --name winget-extras --type Microsoft.PreIndexed.Package --arg https://winget.tplant.com.au/cache. However, that doesn't make the task detect the new source, which makes the situation a million times weirder.

No matter which Winget instances, Winget settings files, or Winget settings folders I try to add new sources to, or even to remove existing sources from, the Winget-AutoUpdate task simply will not acknowledge any changes at all to the 3 default sources, and is still convinced that the msstore, winget and winget-font sources are still active and the only ones enabled.

Trying to change Get-WingetCmd.ps1 so that the functioning $env:LocalAppData\Microsoft\WindowsApps\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\winget.exe path is set for both $systemPath and $userPath, doesn't work either, as it results in the log error message Critical: Winget not installed or detected, exiting...

What version of WAU has the issue?

2.12.0

What version of Windows are you using (ex. Windows 11 22H2)?

Windows 11 25H2 Pro for Workstations x64

What version of winget are you using?

1.30.100-preview

Log information

(From the updates.log file:)

#################################################################
#    14.09.2026 - CHECK FOR APP UPDATES (System context - Connected user)
#################################################################
21:23:12 - Reading WAUConfig
21:23:12 - Notification Level: Full. Notification Language: Norsk (bokmål)
21:23:12 - Checking internet connection...
21:23:13 - Connected!
21:23:13 - Checking prerequisites...
21:23:13 - VC++ x64 already installed (14.51.36247.0)
21:23:14 - WinGet installed version: 1.30.100-preview | WinGet available version: 1.29.290
21:23:14 - -> WinGet is up to date.
21:23:14 - Prerequisites checked. OK
21:23:14 - Selected winget instance: \Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.30.100.0_x64__8wekyb3d8bbwe\winget.exe
21:23:14 - WAU current version: 2.12.0
21:23:14 - WAU AutoUpdate is Enabled.
21:23:14 - WAU is up to date.
21:23:14 - WAU uses Black List config
21:23:15 - -> Successfully loaded local excluded apps list.
21:23:15 - Checking application updates on Winget Repository named 'winget-extras' ..
21:23:15 - No update found. 'Winget upgrade' output:
No sources match the given value: winget-extras
The configured sources are:
  msstore
  winget
  winget-font

21:23:15 - No new update.
21:23:15 - End of process!

Additional information

Recent preview builds of Winget started enforcing a new policy in which portable apps installed through Winget can only be uninstalled in a regular shell and not in an admin shell, for some incomprehensible reason (Allegedly due to, quote, "security").

This by itself necessitates enabling the Winget-AutoUpdate-UserContext task in the first place, which was how I ended up stumbling across many details of this glitch.

Start with Get-WingetCmd.ps1 and Winget-Upgrade.ps1, then reproduce the system-context task using the logged WinGet executable and source commands. Compare source detection in system and user contexts, using updates.log to trace the selected instance and configured sources. Done means configured sources such as winget-extras are recognized by the system-context task without breaking WinGet detection.