Repository navigation
Failing to add WinGet Source in non-interactive session #6334
Description
Activity
- changed the title
[-]WinGet Source in non-interactive session[/-][+]Failing to add WinGet Source in non-interactive session[/+]on Jun 26, 2026 Just for some background information I am trying to get a
wingetmodule written for Ansible to drive winget operations. As Ansible runs in a non-interactive session and in a lot of uses cases are run from newly provisioned machines it is going to be a non-starter if winget does not work at all in these scenarios. It also puts a very poor look on Ansible if our module fails due to limitations and problems in the winget side that we cannot overcome. The workaround I listed does technically get things working for us but it is not something I would be wanting to rely on and tell our users as it is based on an implementation detail and can change in the future.I'm happy to share whatever information is needed to try and unlock this use case but ultimately my skills of debugging this problem have reached a limit and it seems like there's some more deep level MSIX packaging problems that are going to be the root cause.
Jordan Borean (@jborean93) - Have you tried using
Add-WinGetSourcefrom the Microsoft.WinGet.Client Powershell Module?As Demitrius Nelon (@denelon) noted in #5398, The WinGet CLI was designed for a logged in user as it's delivered via an MSIX package (App Installer)
Have you tried using Add-WinGetSource from the Microsoft.WinGet.Client Powershell Module?
The source is present in the winget configuration and you can see it with
winget source list. It's just that when winget goes to use this source it fails to initialise it. UsingAdd-WinGetSourcejust fails anyway because it is already registered (it also seems like it is just wrappingwinget source add ...so not really offering anything on top.)PS C:\Users\Administrator> Add-WinGetSource -Name winget -Argument https://cdn.winget.microsoft.com/cache Add-WinGetSource : Winget command 'source add' with parameters '--name "winget" --arg "https://cdn.winget.microsoft.com/cache"' failed with exit code '-1978335220'. At line:1 char:1 + Add-WinGetSource -Name winget -Argument https://cdn.winget.microsoft. ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Add-WinGetSource], WinGetCLIException + FullyQualifiedErrorId : RuntimeException,Microsoft.WinGet.Client.Cmdlets.Cmdlets.AddSourceCmdletFor Ansible's particular use case, the PowerShell module isn't builtin and we can only rely on what Windows ships with which rules out using it.
Even if we were to try and use the PowerShell module's
Get-WinGetPackageinstead ofwinget listit fails with the following in the same scenario:PS C:\Users\Administrator> Get-WinGetPackage -Source winget Get-WinGetPackage : An error occurred while connecting to the catalog. At line:1 char:1 + Get-WinGetPackage -Source winget + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [Get-WinGetPackage], CatalogConnectException + FullyQualifiedErrorId : RuntimeException,Microsoft.WinGet.Client.Commands.GetPackageCmdletThe debug logs have:
2026-06-26 20:44:59.401 [CORE] WinGet, version [1.9.25200], activity [{5A81D8E8-6837-470A-8EB6-EB026C8E367F}] 2026-06-26 20:44:59.401 [CORE] OS: Windows.Server v10.0.26100.32995 2026-06-26 20:44:59.401 [CORE] Command line Args: "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.24.25200.0_x64__8wekyb3d8bbwe\WindowsPackageManagerServer.exe" -- manualActivation 2026-06-26 20:44:59.401 [CORE] Package: Microsoft.DesktopAppInstaller v1.24.25200.0 2026-06-26 20:44:59.401 [CORE] IsCOMCall:1; Caller: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe 2026-06-26 20:44:59.416 [REPO] Named source requested, found: winget 2026-06-26 20:44:59.433 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB 2026-06-26 20:44:59.434 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB 2026-06-26 20:44:59.475 [CORE] Downloading to path: C:\Users\Administrator\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix 2026-06-26 20:44:59.475 [CORE] Started applying motw to C:\Users\Administrator\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 3 2026-06-26 20:44:59.477 [CORE] Finished applying motw 2026-06-26 20:44:59.477 [CORE] WinINet downloading from url: https://cdn.winget.microsoft.com/cache/source2.msix 2026-06-26 20:44:59.478 [CORE] Default proxy is not set 2026-06-26 20:44:59.509 [CORE] Download hash: 3c07841922a3154962436099520d006614ab6806ead7c0e9743c1af4a2dc9135 2026-06-26 20:44:59.509 [CORE] Download completed. 2026-06-26 20:44:59.593 [CORE] Started trust validation of msix at: C:\Users\Administrator\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix 2026-06-26 20:44:59.648 [CORE] Result for certificate chain validation of Microsoft origin: 0 2026-06-26 20:44:59.689 [CORE] Result for trust info validation of the msix: 0 2026-06-26 20:44:59.689 [CORE] Starting AddPackage operation #0: file:///C:/Users/Administrator/AppData/Local/Temp/WinGet/Microsoft.Winget.Source_8wekyb3d8bbwe.msix Options: { SkipReputationCheck = 1, ExpectedDigests = {} } 2026-06-26 20:44:59.691 [CORE] Begin waiting for operation #0 2026-06-26 20:44:59.691 [CORE] Begin blocking for operation #0 2026-06-26 20:44:59.766 [CORE] Successfully completed #0 2026-06-26 20:44:59.774 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB 2026-06-26 20:44:59.774 [REPO] Package not found Microsoft.Winget.Source_8wekyb3d8bbwe 2026-06-26 20:44:59.774 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(446)\WindowsPackageManager.dll!00007FFC9DAF844 3: (caller: 00007FFC9DADDF3A) Exception(1) tid(16b4) 8A15000F 2026-06-26 20:44:59.774 [CLI ] Caught wil::ResultException: C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(446)\WindowsPacka geManager.dll!00007FFC9DAF8443: (caller: 00007FFC9DADDF3A) Exception(1) tid(16b4) 8A15000FIt fails in the same way as
winget listwhere it tries to add theMicrosoft.Winget.Source_8wekyb3d8bbwe.msixpackage, was told byAddPackageAsyncthat it worked but then failed to find it just likewinget list.As the PowerShell module seems to be using the COM API it seems like the last alternative, using COM, is also going to fail but as COM is just too complex and with no easy examples available I haven't tested that assumption.
As Demitrius Nelon (@denelon) noted, The WinGet CLI was designed for a logged in user as it's delivered via an MSIX package (App Installer)
The
Microsoft.DesktopAppInstaller_8wekyb3d8bbweMSIX package is still needed for any winget operation, not just the CLI, so MSIX is a fundamental part of winget itself. When attempting to use the PowerShell winget module withoutMicrosoft.DesktopAppInstallerbeing added for the user then the whole PowerShell process crashes.What is hard to swallow about these statements is that the alternatives (PowerShell module, COM API) also fail in the same way as the CLI and running in non-interactive environments is not an uncommon use case. The fact that I can manually add the source package in PowerShell inside the same environment, either through
Add-AppxPackageor calling theAddPackageAsyncAPI like winget does, and it works tells me that there's something weird going on inside winget itself. I don't know whether it's because the winget core is being run inside some sort of appcontainer or some other isolated environment but this is essentially a hard blocker behind Ansible creating our own wrapper around winget.I don't know why
AddPackageAsyncis reporting it being successful2026-06-26 20:44:59.689 [CORE] Starting AddPackage operation #0: file:///C:/Users/Administrator/AppData/Local/Temp/WinGet/Microsoft.Winget.Source_8wekyb3d8bbwe.msix Options: { SkipReputationCheck = 1, ExpectedDigests = {} } 2026-06-26 20:44:59.691 [CORE] Begin waiting for operation #0 2026-06-26 20:44:59.691 [CORE] Begin blocking for operation #0 2026-06-26 20:44:59.766 [CORE] Successfully completed #0But then it actually isn't
2026-06-26 20:44:59.774 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB 2026-06-26 20:44:59.774 [REPO] Package not found Microsoft.Winget.Source_8wekyb3d8bbwePS C:\Users\Administrator> Get-AppxPackage Microsoft.Winget.Source PS C:\Users\Administrator>On a final side note,
Repair-WinGetPackageManager -Verbose(which also fixes the problem) shows that it is doing the exact same thing as my workaround:PS C:\Users\Administrator> Repair-WinGetPackageManager -Verbose VERBOSE: Creating MTA thread VERBOSE: No version specified. VERBOSE: Running winget.exe with ----version VERBOSE: Executing Appx cmdlet Get-AppxPackage -Name Microsoft.Winget.Source VERBOSE: Integrity category type: WinGetSourceNotInstalled VERBOSE: Installing winget source VERBOSE: Downloading https://cdn.winget.microsoft.com/cache/source2.msix VERBOSE: Size 3234267 bytes VERBOSE: Executing Appx cmdlet Add-AppxPackage -Path C:\Users\Administrator\AppData\Local\Temp\14897f69-0e5d-4a8f-8f18-46788a57b324\source2.msix -ErrorAction Stop VERBOSE: Running winget.exe with ----version VERBOSE: Executing Appx cmdlet Get-AppxPackage -Name Microsoft.Winget.Source VERBOSE: WinGet is in a good state.It just hardcodes the URL like I do so is subject to the exact same problems of I listed in the original post. The module is also not available inbox with winget and as stated before I cannot rely on it for Ansible's use case.
- added a commit that references this issue
on Jul 5, 2026 Jordan Borean (@jborean93)
One of the things I noticed in the log is the WinGet version. I'd suggest upgrading to the latest stable version before trying to use WinGet. There are certainly still plenty of rough edges and things that haven't been implemented yet, but several things have been fixed since then.I suspect the target devices was a "fresh" installation based on that WinGet version. It shipped in November of 2024. The version of WinGet included in "new" OS builds is often outdated due to the long release cycle of Windows. We built the Repair-WinGetPackageManager cmdlet to make it easier to update WinGet.
The "Pre-Indexed Package" WinGet uses for the default source is available at https://cdn.winget.microsoft.com/cache/source2.msix. Installing that on the remote device may help with the problem in the short to medium term (your note about changes is valid). You may have better success using the WinGet Client PowerShell module, but it does have a dependency on PowerShell 7 for full functionality.
We do have other OS work to make this scenario possible, but packaged applications (like AppInstaller and modern PowerShell) were designed for interactive users as opposed to remote system administration scenarios. There is progress, but the long release cycles and compatibility concerns around Windows make it very hard to give any kind of responsible ETA.
The issue you encountered is more of an OS problem and less of a WinGet problem. Either way, it's a Microsoft problem and we are working on it.
One of the things I noticed in the log is the WinGet version. I'd suggest upgrading to the latest stable version before trying to use WinGet. There are certainly still plenty of rough edges and things that haven't been implemented yet, but several things have been fixed since then.
What is the way to do that,
Add-AppxPackagethe msix bundle from a GitHub release? How does that line up with Windows servicing and updates tied to the OS lifecycle?The "Pre-Indexed Package" WinGet uses for the default source is available at https://cdn.winget.microsoft.com/cache/source2.msix. Installing that on the remote device may help with the problem in the short to medium term (your note about changes is valid)
It does workaround the problem but
- This URL does not seem to be stable, it seems to have changed from
source.msixtosource2.msixin the past and more of an implementation detail - By adding it manually I seem to be doing the same thing that winget is doing but for some reason winget is failing which seems like something that should be investigated/fixed (if not already)
You may have better success using the WinGet Client PowerShell module, but it does have a dependency on PowerShell 7 for full functionality.
Alas we cannot add yet another dependency, customers will essentially want us to work with what is in box (PowerShell 5.1, no module). If we say you need to bootstrap x, y, z, then they won't be happy and push back asking why we can't use what ships with the OS.
We do have other OS work to make this scenario possible, but packaged applications (like AppInstaller and modern PowerShell) were designed for interactive users as opposed to remote system administration scenarios
I can understand that, the reason why I opened the issue in the first place though is that the problem doesn't seem to be fundamental but rather a bug with
winget. The fact that I can get this working by manually downloading and adding thesource2.msixpackage in PowerShell, in the same SSH logon session as winget failing, indicates it does work in a non-interactive session but something is going on with howwinget.exeis doing so and needs further investigation.- This URL does not seem to be stable, it seems to have changed from
Jordan Borean (@jborean93) I've updated #6347 to keep a validated local copy of the
wingetsource when its packaged extension cannot be deployed. This is intended to avoid the manualsource2.msixinstall you described. It is still a PR, not a fix in a released WinGet build.Would you be willing to check a build from that PR in the same SSH/WinRM setup, without preinstalling the source package? The useful check would be
winget list --disable-interactivity --accept-source-agreements --verboseon a fresh user session, then the same command once more to see whether the fallback continues to work. If it still fails, the relevant WinGet log lines around source update/open and the error code would help. Please remove any private paths or machine details before posting logs.I'm especially interested in whether this works for your Ansible use case without adding a PowerShell module or doing an interactive sign-in. If you are open to testing it, I can point you to the exact PR build and setup steps once the build is available.
I'm happy to do a check, we can easily provision a new ephemeral 2025 instances for testing that had the original issue, the trickest bit is figuring out how to deploy the new build in a similar way as winget itself. Testing out a manual build outside of the MSIX packaging environment may just work by virtue of being outside of a packaged application so I need to be careful when verifying the fix.
This was generated by AI during triage.
Category: bug · State: needs-triage — additional evidence for the in-flight fix.
Independent confirmation that the non-interactive
0x80070520is not limited to source setup:winget uninstallof a Store/MSIX package hits the identical code path and error. Filed with full root cause as #6579; summary here since a fix is being verified in the packaged context.Repro on Windows 10 Pro 19045, winget v1.29.380, Session 0 (non-interactive):
winget uninstall claude Found Claude [Anthropic.Claude] Starting package uninstall... Uninstall failed with exit code: 0x80070520 : A specified logon session does not exist. It may already have been terminated.winget log:
[CLI ] Removing MSIX package: Claude_2.19675.0.0_x64__pzs8sxrjxfjjc [CORE] Starting RemovePackage operation #2: Claude_2.19675.0.0_x64__pzs8sxrjxfjjc [CORE] Deployment operation #2: A specified logon session does not exist. It may already have been terminated. [FAIL] ...\AppInstallerCommonCore\Deployment.cpp(54)... 80070520 A specified logon session does not exist... [CLI ] MSIXUninstall uninstaller failed: 2147943712Path:
UninstallFlow.cpp:416→Deployment::RemovePackage(Deployment.cpp:277,RemovePackageAsync) →WaitForDeployment(Deployment.cpp:54,THROW_HR_MSG(deployResult.ExtendedErrorCode(), ...)).Counter-scenario (packaging, not the session): in the same Session 0, in-box
Remove-AppxPackage -Package Claude_2.19675.0.0_x64__pzs8sxrjxfjjcsucceeded — the non-packaged cmdlet path works where winget's packagedPackageManagercall does not. Consistent with the appcontainer note above. Full detail: #6579.
Relevant area(s)
WinGet CLI
Relevant command(s)
winget list
Brief description of your issue
When running winget in a non-interactive session, like ssh/winrm, any operations that need to setup the winget source will fail. By default 2 sources seem to be available out of the box
msstoreandwingetwheremsstorewon't work until at least one interactive logon has happened for that user andwingetwhich fails to register theMicrosoft.Winget.Source_8wekyb3d8bbwepackage.On investigation I can see in the winget logs the following
The key parts I've found is that winget goes to register/add/install the
Microsoft.Winget.Source_8wekyb3d8bbweMSIX package fromhttps://cdn.winget.microsoft.com/cache/source2.msix. The first one fails withThe second attempt "succeeds" but when it goes to try and use that package it fails to then find it
If the source was setup in an interactive logon, like RDP, then
winget listin SSH works at least for that current source package but if winget every needs to add it again for any reason it will fail in these non-interactive sessions.Some things I've noticed is that even when
winget listfails and the logs indicate that it successfully added on the second attempt, the package does NOT appear inGet-AppxPackageor inC:\Program Files\WindowsApps. I have no idea why theAddPackageAsyncoperation is saying it succeeded but in reality didn't but there's fundamentally no reason why it should fail in a non-interactive session.I haven't looked into the
msstoresource problem but it's solved by having the user log on interactive once but I don't care too much about that one for now.The only work around I have is to manually add the source package
This is not a good workaround because
I've even used PowerShell to call the exact same AddPackageAsync API that winget is using and PowerShell works without any issues. There's something about the MSIX appcontainer that winget is running in that's causing problems.
I assume this is a duplicate of these two issues
Steps to reproduce
Create a brand new Windows Server 2025 image, I'm using an Amazon EC2 instance. Create an admin user and make sure to never log on through RDP. Connect through SSH and run
Expected behavior
winget listworksActual behavior
Environment