The command winget upgrade --all is Microsoft’s built-in answer to scattered, time-consuming app updates. But pulling the trigger without understanding its limits can leave you with partially updated software, skipped apps, or silent agreement to license changes. Here’s how to use it safely.
A recent walkthrough from Neowin has resurfaced one of Windows’ most useful, yet underappreciated, power-user features: the ability to batch-update almost all your desktop applications and Microsoft Store apps using a single command-line instruction. But the feature, introduced with the Windows Package Manager, carries nuances that can trip up even experienced users.
What the --all flag actually does
When you run winget upgrade --all in PowerShell or Command Prompt, WinGet scans your installed applications against every package source it has configured. By default, that includes Microsoft’s Store repository and the open-source winget-pkgs repository on GitHub. If it finds a match with a newer version available, it downloads the installer and runs it—often silently or with minimal interface.
But think of WinGet as a conductor that can only direct the players it recognizes. Applications installed outside those known sources, or those with version strings that don’t match a package manifest, are simply ignored. No error, no warning at the end of the batch—they just stay stale.
Microsoft’s documentation, and the Neowin guide, underscore that this is not a magical “update every app” button. It’s a powerful automation wrapped around community-maintained package definitions, and its coverage depends entirely on the repositories you’ve added. If you’ve never added a third-party source (like --add-repo), you’re limited to what Microsoft and the winget community have catalogued.
What you see before the update
Before you let the updater loose, run this:
winget upgrade
That lists every application WinGet thinks is outdated, showing the current installed version and the version it would fetch. To get a cleaner view without the full package detail, Microsoft recommends:
winget list --upgrade-available
If the list looks right—no critical apps missing, no unexpected rollbacks—then you can proceed with winget upgrade --all. If you only want to update, say, Google Chrome, use the package ID for precision: winget upgrade --id Google.Chrome.
The limitations Microsoft doesn’t advertise loudly
Three exceptions catch users by surprise.
-
Apps without detectable version numbers. Some installers don’t stamp a version in the registry in a way WinGet can read. Those get skipped unless you add
--include-unknown. This can be dangerous because WinGet has no way to verify whether the unknown version is newer or older; it simply trusts the package source. -
Pinned packages. You can pin a specific app version to prevent it from being changed, which is great for testing or compatibility. But
--allrespects pins by default. If you’ve ever pinned anything and forgot, you’ll need--include-pinned—though that defeats the purpose of pinning. -
Selective repository matching. An app installed from a custom
.msifile might have a product code that perfectly matches a winget package, but if the installed version uses a non-standard format, the upgrade may fail silently. WinGet doesn’t retry with alternative manifests.
A 2023 update to the WinGet client improved matching for Microsoft Store apps, but third-party desktop apps remain a patchwork. For example, an application installed from a vendor’s own download page might be the exact same binary as the winget package, yet WinGet may not connect the dots if the registry metadata differs.
How we got here: From Add/Remove Programs to a package manager
Windows has long suffered from fragmented software management. Third-party updaters like Chocolatey and Ninite filled the gap for years, each with their own repository and syntax. Microsoft recognized the gap and launched Windows Package Manager in May 2020, first as an open-source preview, then as a built-in tool in Windows 10 version 1809 and later, and now a first-class citizen in Windows 11.
The winget client is community-driven at its core. The package repository on GitHub accepts pull requests from anyone, under Microsoft’s curation. This means coverage can be broad—from 7-Zip to Zoom—but quality varies. Microsoft has steadily improved the engine: version 1.7 added the --upgrade-available list flag, and 1.8 enhanced experimental features like --wait. The client itself updates via the Microsoft Store, so it quietly evolves in the background.
Yet the dream of a universal Windows updater remains just that. Windows Update handles the OS and some drivers; Microsoft Store auto-updates by default; but the long tail of Win32 apps still relies on winget or the user’s vigilance.
What you should do now, based on your role
If you’re a home user
- Once a month: Open PowerShell or Command Prompt and run
winget upgrade. - Review the list. Look for any surprises—apps you didn’t know were installed, versions that look wrong.
- If it looks good, run
winget upgrade --all. Accept the default prompts so you can read license terms for major updates. - Avoid
--accept-source-agreementsand--accept-package-agreements; you want to see what you’re agreeing to, especially for freeware that might bundle extras.
If you’re a Windows power user
- Add
--include-unknownonly if you know what it does. If a critical app like Notepad++ shows no version, you may need it. But test first on a non-production machine. - Use
--include-pinnedsparingly. If you have pinned versions for a reason, keep the pin. Run separate targeted updates for those apps when you’re ready to test.
If you’re an IT administrator
- Automation with restraint. A Task Scheduler job can run
winget upgrade --all --accept-source-agreements --accept-package-agreementson a schedule, but never do this on production endpoints without a testing ring. - Set the task to run with a 5-10 minute delay after startup to ensure network and services are ready. Run under a dedicated service account with local admin rights, but not Domain Admin.
- Log everything: Add
--logto capture output to a file for later review. A successful exit code from winget does not mean all apps updated; it just means the client finished its pass. - Consider policy: In regulated environments, silent acceptance of package agreements may violate change control procedures. Weigh the benefit of automation against compliance requirements.
- Test the command interactively first. Run it from a test VM or a user’s machine while watching exactly what happens. Some installers demand elevation or attempt to close running applications, which can cause data loss.
Quick reference
| Command | What it does |
|---|---|
winget upgrade |
Lists available updates |
winget list --upgrade-available |
Shows only packages with upgrades ready |
winget upgrade --all |
Updates everything WinGet recognizes |
winget upgrade --id Package.Id |
Updates a specific package only |
winget upgrade --all --include-unknown |
Includes packages with unreadable versions |
winget upgrade --all --include-pinned |
Overrides pinning for all packages |
The outlook for Windows app management
Microsoft’s roadmap suggests tighter integration between WinGet, Intune, and Windows Update for Business. The ability to deploy and update third-party apps alongside OS patches through a unified management plane is a clear goal. For consumers, a rumored “App Health” dashboard may one day surface WinGet’s capabilities in a graphical interface—no command line needed.
But until then, winget upgrade --all remains a raw power tool. It’s a time-saver for the tech-savvy, a potential pitfall for the unwary, and a step toward a future where maintaining your PC doesn’t require clicking through a dozen update dialogs.