winget-cli
winget-cli copied to clipboard
upgrade '--all' and '--accept-package-agreements' flags should work together
Description of the new feature / enhancement
I tried to use the command winget upgrade --all command but after the package repos were successfully downloaded, it aborted because the package-agreements werent accepted. But I was not asked either if I tried to upgrade all. So I tried to append the --accept-package-agreements flag, but assumingly this won't work in combination with --all.
The annoying part is that it abborts the whole proccess of upgrading all packages and wont continue. So I have to manually upgrade all packages with included package-agreements in order to accept it, and then use --all to upgrade all others.
Without using both flags in combination it makes the whole purpurse of --all obsolete because it wont run no matter if you want or wont want to accept the package agreements
Proposed technical implementation details
I want the command winget upgrade --all --accept-package-agreements to work and upgrade all packages and automatically accept the agreemets, if nessecary.
Just had the same issue, one program wouldn't upgrade with "Package agreements were not agreed to. Operation cancelled." "The arguments provided can only be used with a query." with "winget upgrade --accept-package-agreements --all" Ended up just uninstalling the software that was causing issues and upgraded the rest.
Yeah, this is not good for automation. Also make sure that --accept-source-agreements is also compatible.
I have this problem when I install using Windows Store source, because I am prompted to accept the agreement upon install and every update.
winget --all will fail with:
Package agreements were not agreed to. Operation cancelled.
The workaround has been to first use winget or Store app to update the store sourced package(s), then winget --all will update the remaining winget sourced packages that I have.
Please enable this combination so that there can be one command to update "all" packages:
winget upgrade --all --accept-package-agreements --accept-source-agreements
Just adding that this definitely needs to be fixed:
winget upgrade --all --accept-package-agreements --accept-source-agreements
What's the point in having an upgrade --all flag if the flag won't even work?
If I can do an rpm -Uvh or apt-get -y upgrade on Linux, I should be able to do an winget upgrade --all --accept-package-agreements --accept-source-agreements as well.
I will bump this as well. This must be fixed ASAP.
This is a rather serious UX issue, with what appears to be an easy fix. Would be great to get some ETA update/feedback from the MS Team.
as a workaround you're able to enter the Y automatically by piping it in powershell
ECHO Y | winget upgrade --all --silent
ECHO Y | winget upgrade --all --silent
Didn't work for me.
This should really be fixed. Either allow --all --accept-package-agreements --accept-source-agreements, or add a separate command like winget agreements --accept-all that flags any upgrades with "accepted" license terms so that the upgrade can proceed.
ECHO Y | winget upgrade --all --silent
Didn't work for me.
This should really be fixed. Either allow
--all --accept-package-agreements --accept-source-agreements, or add a separate command likewinget agreements --accept-allthat flags any upgrades with "accepted" license terms so that the upgrade can proceed.
Yeah looks like I missed a bit. In powershell this works for me
ECHO Y | cmd /c winget upgrade --all --silent
Does this merge mean it's been fixed?
Does this merge mean it's been fixed?
seems it has been released in preview version - https://github.com/microsoft/winget-cli/releases/tag/v1.5.101-preview
"Copy install behavior flags on upgrade --all by @florelis in https://github.com/microsoft/winget-cli/pull/2794"
waiting for release version. don't wanna mess with pre-release version personally
PR Merged is just an indication that code has been merged in "main" branch (assuming that's the target). Releases have links to included PRs (in this case it's in a preview release). If the work has been merged for the scope indicated in the issue, then the issue can be closed. A closed issue is not an indication that the "fix" or "feature" is in a release yet.
For this issue, additional work to be able to close it is in progress with:
- https://github.com/microsoft/winget-cli/pull/2862
Once that work is complete and verified, this issue will be closed.
It will not be available (other than in a developer's individual build) until we cut our next "preview" release after it has been merged.
When we cut the next "stable" release after the work is in a "preview" release, then it will be GA (Generally Available).
This is being tracked in our 1.5 milestone.
I'm trying to use the command winget upgrade --all --accept-package-agreements --accept-source-agreements but appear another error: The arguments provided can only be used with a query. How do I resolve this?
We've validated the referenced PR addresses these concerns.
This fix will be available in our next preview release after 1.5-preview(1).
winget upgrade -u -h -r --accept-source-agreements --accept-package-agreements
Is there something wrong with the above command? it gives me this error: "The arguments provided can only be used with a query."
If I remove the last two agreement commands I get this error: "Package agreements were not agreed to. Operation cancelled."
No package has been specified for the upgrade. If you want to upgrade all packages add "--all".
Can confirm that the latest preview release does honor the switches. This was my Powershell:
Add-AppxPackage c:\temp\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle winget upgrade -h --all --accept-package-agreements --accept-source-agreements
I do have a question though. I thought WinGet was supposed to update all Store Apps with the -all switch? When I open the Microsoft Store app on Windows 11, it shows more stuff. Example is on a newly upgraded machine from Windows 10, the Snipping Tool has an updated version, but the winget command above does not find it and update it. I have to do that manually via the store. I've tried running the command with Administrator and User context. Is there a reason for this? Just some examples in my attached snip.

No package has been specified for the upgrade. If you want to upgrade all packages add "--all".
The help menu shows that -r and --all are the same. But I also tried it with --all and got the same error.
Try winget upgrade -uhr --accept-source-agreements --accept-package-agreements
Any Microsoft Store packages installed with WinGet will show version "Unknown", and Microsoft Store packages not installed with WinGet will not be included. We have future work to address this.
The source and package agreements are only necessary for the Microsoft Store source.
So how do we deal with this in the meantime? What is the scripted way to update all Store apps on a computer? We want to do this on a recurring basis with our monthly application patching process like we do with other apps. All of the forums I read say "use winget for Windows 11" but this appears to not yet be supported.
And btw, this -uhr switch appears to update our Microsoft Office 365 Apps for Enterprise, which we DO NOT want. I find this bizarre that winget would somehow manage this when we deploy it via ODT. Do you also have a command line for exclusions in the works?
So how do we deal with this in the meantime? What is the scripted way to update all Store apps on a computer? We want to do this on a recurring basis with our monthly application patching process like we do with other apps. All of the forums I read say "use winget for Windows 11" but this appears to not yet be supported.
I was wondering about this, too. Has been an issue especially with per-user apps and not being able to upgrade the Store apps without having to open the Store manually. Hopefully this could be rolled up into Winget maybe so they can get upgraded at the same time - handy for auto-maintenance/scripting/new computer builds/imaging etc!
Bump. This needs to be fixed! A real package manager should require no user input when directed to do so. There should be UAC bypasses for these updates as well as this is core security SOP..
I am not agreeing with the UAC bypass tough. I run my command prompt as admin if necessary. That will bypass it but you need to keep in mind that it will run every installer as admin.
That gets tricky... some installers change the location depending on how they are run (e.g. non-elevated goes to %localappdata% and elevated goes to %programfiles%). So if you elevate your terminal, you may see a difference in behavior (possibly unwanted), but if you don't elevate it, your command may not succeed.
Just to bring this topic back around. The original request was for the cli to update all installed store apps when it currently does not.
@brinham I'd suggest creating a new issue, but I can share:
We need to get the version information from the Microsoft Store REST source so we know when there are available updates to those packages. Currently, we only get "Unknown" version for UWP and Win32 packages. Some work has been done to get version for Win32 packages, but not in all the endpoints, and sadly the one we need for version comparison still renders "Unknown". We're working with them to unblock the scenario.
Any updates? I still get that error.
~~still get this error, still seemingly no way to accept all the agreements.~~
edit: you have to do BOTH, they silently fail and don't stick otherwise. The fact that these aren't y/n prompts is sort of obtuse, too.
winget upgrade --all --accept-source-agreements --accept-package-agreements
For some reason, I still need to explicitly accept *.
If you are PowerShell, came up with this workaround,
Edit PowerShell profile
code $PROFILE
# or
notepad $PROFILE
Add the following function,
# Short command to upgrade all the installed packages
function Winget-Upgrade-All() {
winget upgrade --all --accept-source-agreements --accept-package-agreements
}
Execute from PowerShell
Winget-Upgrade-All