You can, but preview first. Microsoft's documentation says winget upgrade with no arguments shows apps that have available updates, and the all option attempts to install every one. On a developer machine, read the list, update in small batches, and keep a record, so one bad release does not break your toolchain unnoticed.
What the commands do
The Windows Package Manager documentation describes three uses of the upgrade command.
- Run it with no arguments to list installed applications that have an update available.
- Run it with a package identifier to upgrade a single app, for example by passing its ID.
- Run it with the all option, which looks for all applications with updates and attempts to install them. You can also name several apps in one command.
The page advises using upgrade without arguments first to preview which apps will be upgraded. That is the habit to build.
Why not just run all
A developer laptop has an unusual mix of software: compilers, runtimes, container tools, database clients, editors, and plugins that depend on exact versions. A blanket upgrade changes all of those at once. If your build breaks afterwards, you do not know which change caused it.
There is also a trust question. Each update is code arriving from a publisher, and you have not looked at any of them. Updates are still the main way security fixes reach you, so the answer is not to stop. It is to make updates visible and spaced.
A practical method
- Run the no-argument form and copy the list into your notes.
- Sort it into groups: system and security tools, editors and runtimes, and everything else.
- Upgrade the first group right away. Fixes there matter most.
- Upgrade runtimes and build tools one at a time, then run your project's build and tests.
- Upgrade the rest weekly or monthly.
- Note anything you do not recognise and decide whether to remove it.
On a shared team, agree a cadence so people are not each doing something different. Our post on automatic update policy for small organisations offers a starting point.
Pinned versions
Projects often need a fixed runtime version. Record those in the repository rather than relying on whatever is installed. See pinning runtime and SDK versions.
When something breaks after an upgrade
Keep the list you copied before upgrading. If the build fails afterwards, the list tells you what changed, so you can look at the most likely suspect first, usually a compiler, runtime or SDK. Check the publisher's release notes, and see whether the project pins a version you should be using. If you must roll back, do it for that one tool and record why, so the next person does not repeat the upgrade blindly.
Also decide who owns the decision. On a managed fleet, an administrator may control sources and timing, so ask before changing your own settings.
What winget will not cover
It manages apps available through its sources. Editor extensions, language level tools, and apps installed by hand have other update paths. Our inventory post shows commands for several ecosystems.
Quick check
How do I see what winget would upgrade?
Run winget upgrade with no arguments. Microsoft's documentation suggests doing this before using the all option.
Can I upgrade a single app?
Yes. Pass its package ID to the upgrade command.
Sources
Last reviewed: 19 October 2026.
