You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I tried to do winget install 7zip and then it automatically triggers a reboot on my PC. It's not a good user experience. I think you should suppress the reboot after installation unless explicitly specified.
peterjc123 the current implementation of the client 0.1 doesn't support a forced reboot. If an installer does, it's outside of the winget.exe client. You may have encountered a bug. I haven't been able to reproduce this in my test VM.
modified the milestones: This milestone has been deleted, This milestone has been deleted, This milestone has been deleted, This milestone has been deletedon May 3, 2021
I just installed LibreOffice with Winget and it rebooted Windows, causing me to lose quite a bit of work! That is definitely NOT a good experience.
Yes, I understand that it's LibreOffice's installer doing that, but this really needs to be fixed one way or another -- the PC should not be rebooting all of a sudden, with zero warning or anything. I don't even care how it gets fixed, maybe Windows needs a way for Winget to be able to inhibit reboots or something, I have no idea, but it's just not reasonable to expect Winget - users to close all of their open work and (attempt to) save their things when installing something, just in case Windows reboots without any prompt at all.
Reacted by Demitrius Nelon, Chris Galvan, Michael Kellner, Kaleb Luedtke, Claudio Tanci, Marek Lukáš, d79, Jan Klass, Sergio Alonso Pascual, Antanas Domarkas and 3 more
I had this issue while installing Visual Studio in my new computer. It did reboot in the middle of installation.
I use a script to setup all my dev tools/apps and everything was good and dandy until it rebooted, there was not way to resume or know what programs installed or not.
Not sure if scripting is the way to go here or if even is a supported scenario but would be great to handle the reboots so I can finish intalling then rebooting.
Hi, is there been any progress in the last 10 months on this issue? We would love to silently deploy software, but this may not trigger any reboots....
Hi, is there been any progress in the last 10 months on this issue? We would love to silently deploy software, but this may not trigger any reboots....
We've been holding off deploying this for years now because of this issue. We're not about to switch over to an app management system that sometimes reboots machines.
How this hasn't been a critical priority issue I'll never know.
Amazingly enough, this is not, in fact, the only issue that exists for the entire project, and figuring out why the installers are misbehaving and how to work around it isn't exactly simple.
And no, spamming 'shutdown -a' will not work. All that does is abort any existing shutdown timer. It doesn't do anything if a timer isn't used or if something uses one of the dozen other ways that exist to cause a reboot.
........many people use it all the time. I use it practically every day, to the point that I don't even bother going to sites to download things anymore, I just grab it through Uniget, which is just a GUI frontend for winget
........many people use it all the time. I use it practically every day, to the point that I don't even bother going to sites to download things anymore, I just grab it through Uniget, which is just a GUI frontend for winget
Sure it's a great random reboot generator that also installs software. I use it at home too. Not really suitable for an enterprise environment though.
Does Winget have any real interest of dealing with this issue, as far as its whole design philosophy goes? It would appear to me that things like this issue are basically out of scope for it.
All it really does (for the most part) is download and run installers (or copy files and add a path to PATH for portable software), doesn't it? Which is not meant to downplay the work that goes into Winget - I just mean that Winget's design philosophy doesn't seem to be to actually control the actual software installation process. I know it calls itself a "Package Manager", but it's really more a "software fetcher", isn't it? It doesn't host any actual packages (just install manifests), it doesn't actually "package" anything, it doesn't maintain its own list of the software it has installed (it just reads from the Windows Registry, and if software doesn't write to that correctly then Winget is helpless - see for the example the still-ongoing issues with managing Discord through Winget). There's also the ongoing issue of dealing with unwanted shortcuts that software creates because it doesn't offer the right install flags to control that... and other issues of that kind. It seems to me that the Winget development team basically just treats all of these as "not our responsibility". Winget is not actually a Package Manager in the way that e.g. Chocolatey or the various Linux Package Managers are.
So I think even something like spamming shutdown -a is out of the scope for Winget. It doesn't want to care about what software installers are doing, it just wants to download and run them and throw its hands in the air about what happens beyond that. I'm not that happy with the state of things myself, when I started using Winget I was under the impression that this is an actual package manager - but I personally no longer believe that now. shrug
I wrote an absolutely canonical MSI package that scheduled a reboot via standard MSI mechanisms. But the way winget was invoking MSI installation converted a scheduled reboot into an immediate reboot. Note that both MSI and winget technologies come from Microsoft, so I believe it is winget responsibility to make them work together is an adequate way (and this has happened, though it took several years: #2499).
Current issue also mentions VCRedist triggering reboots. Who is responsible for fixing this? Microsoft-as-VCRedist-owner or Microsoft-as-winget-owner? In either case, it is Microsoft.
Reacted by Olav Rønnestad Birkeland, Jannik Zuther, Mick 277, Frulfump and nascentt
Requests that WinGet suppress installer-initiated reboots by default, with an opt-in flag to allow reboots when desired.
Current state — the framework is implemented:
WinGet does not initiate a reboot by default; use --allow-reboot to opt in.
Reboot-required installer exit codes are recognized via the manifest ExpectedReturnCodes and handled gracefully: "reboot required to finish" is reported as a success with a warning (no automatic reboot), and a resume-after-reboot flow is available when reboots are allowed.
The MSI case where a scheduled reboot was converted into an immediate reboot has been fixed (see the related PR below).
Remaining gap (why this stays open):
Some installers still reboot even when suppression is requested — most often .exe installers that don't honor a no-restart switch, an MSI that invokes a nested executable without passing the flag through, or updating a running dependency (e.g. VCRedist) that forces a reboot to complete.
These are per-package issues rooted in installer behavior and manifest metadata (correct silent/no-restart switches and ExpectedReturnCodes), rather than something WinGet can universally force at the client level.
Re-scoping:
Keeping this open to track the long tail of packages that reboot despite suppression. Specific offenders are best addressed as per-package manifest fixes (Catalog-Health) so the correct no-restart switches and return codes are captured.
If you hit a package that reboots unexpectedly, please share the exact package identifier and version so it can be triaged against its manifest.
EA App (ElectronicArts.EADesktop) also reboots without consent on update v13.768.7.6285-15019056 and it also removes the app. There was a similar issue I previously reported and was fixed but is probably related (microsoft/winget-pkgs#352972)
No updates on this? IT is a disaster, how can it be allowed for an app updated via cli tool without UI to execute reboot without any warning or consent?!
Activity
Lebrack commentedon May 20, 2020
Are you sure? I intalled 7Zip with no reboot action. Even MSI/EXE classic (manual) installation of 7Zip, don´t triggers a reboot.
peterjc123 commentedon May 20, 2020
Oh, maybe I have an existing 7zip installation. But anyway, we should not trigger reboot automatically.
madcampos commentedon May 21, 2020
If I reboot after a install will winget be able to return to that point and continue after the reboot?
denelon commentedon May 30, 2020
peterjc123 the current implementation of the client
0.1doesn't support a forced reboot. If an installer does, it's outside of the winget.exe client. You may have encountered a bug. I haven't been able to reproduce this in my test VM.blogcraft commentedon Sep 3, 2020
It happened to me while installing Visual Studio Community and Microsoft Teams.
WereCatf commentedon May 11, 2021
I just installed LibreOffice with Winget and it rebooted Windows, causing me to lose quite a bit of work! That is definitely NOT a good experience.
Yes, I understand that it's LibreOffice's installer doing that, but this really needs to be fixed one way or another -- the PC should not be rebooting all of a sudden, with zero warning or anything. I don't even care how it gets fixed, maybe Windows needs a way for Winget to be able to inhibit reboots or something, I have no idea, but it's just not reasonable to expect Winget - users to close all of their open work and (attempt to) save their things when installing something, just in case Windows reboots without any prompt at all.
chrisgalvan commentedon May 26, 2021
I had this issue while installing Visual Studio in my new computer. It did reboot in the middle of installation.
I use a script to setup all my dev tools/apps and everything was good and dandy until it rebooted, there was not way to resume or know what programs installed or not.
Not sure if scripting is the way to go here or if even is a supported scenario but would be great to handle the reboots so I can finish intalling then rebooting.
49 remaining items
xhoy commentedon Feb 26, 2024
Hi, is there been any progress in the last 10 months on this issue? We would love to silently deploy software, but this may not trigger any reboots....
nascentt commentedon Mar 2, 2024
The way Chocolatey does it is by spamming
shutdown -aconstantly whilst doing actions.nascentt commentedon Mar 2, 2024
We've been holding off deploying this for years now because of this issue. We're not about to switch over to an app management system that sometimes reboots machines.
How this hasn't been a critical priority issue I'll never know.
nascentt commentedon Oct 28, 2024
Is Winget abandonware?
No activity on this in half a year. No resolution in 4 1/2 years.
Winget is unusable in this state.
Masamune3210 commentedon Oct 28, 2024
Amazingly enough, this is not, in fact, the only issue that exists for the entire project, and figuring out why the installers are misbehaving and how to work around it isn't exactly simple.
And no, spamming 'shutdown -a' will not work. All that does is abort any existing shutdown timer. It doesn't do anything if a timer isn't used or if something uses one of the dozen other ways that exist to cause a reboot.
nascentt commentedon Oct 28, 2024
I was just stating what chocolatey does in response to denlon.
I'm sure there's many issues remaining in Winget, sadly this is the main one blocking it from being usable in any way.
Masamune3210 commentedon Oct 29, 2024
........many people use it all the time. I use it practically every day, to the point that I don't even bother going to sites to download things anymore, I just grab it through Uniget, which is just a GUI frontend for winget
nascentt commentedon Oct 29, 2024
Sure it's a great random reboot generator that also installs software. I use it at home too. Not really suitable for an enterprise environment though.
Blacklands commentedon Oct 29, 2024
Does Winget have any real interest of dealing with this issue, as far as its whole design philosophy goes? It would appear to me that things like this issue are basically out of scope for it.
All it really does (for the most part) is download and run installers (or copy files and add a path to
PATHfor portable software), doesn't it? Which is not meant to downplay the work that goes into Winget - I just mean that Winget's design philosophy doesn't seem to be to actually control the actual software installation process. I know it calls itself a "Package Manager", but it's really more a "software fetcher", isn't it? It doesn't host any actual packages (just install manifests), it doesn't actually "package" anything, it doesn't maintain its own list of the software it has installed (it just reads from the Windows Registry, and if software doesn't write to that correctly then Winget is helpless - see for the example the still-ongoing issues with managing Discord through Winget). There's also the ongoing issue of dealing with unwanted shortcuts that software creates because it doesn't offer the right install flags to control that... and other issues of that kind. It seems to me that the Winget development team basically just treats all of these as "not our responsibility". Winget is not actually a Package Manager in the way that e.g. Chocolatey or the various Linux Package Managers are.So I think even something like spamming
shutdown -ais out of the scope for Winget. It doesn't want to care about what software installers are doing, it just wants to download and run them and throw its hands in the air about what happens beyond that. I'm not that happy with the state of things myself, when I started using Winget I was under the impression that this is an actual package manager - but I personally no longer believe that now. shrugslonopotamus commentedon Oct 29, 2024
Well, I do not fully agree.
I wrote an absolutely canonical MSI package that scheduled a reboot via standard MSI mechanisms. But the way winget was invoking MSI installation converted a scheduled reboot into an immediate reboot. Note that both MSI and winget technologies come from Microsoft, so I believe it is winget responsibility to make them work together is an adequate way (and this has happened, though it took several years: #2499).
Current issue also mentions VCRedist triggering reboots. Who is responsible for fixing this? Microsoft-as-VCRedist-owner or Microsoft-as-winget-owner? In either case, it is Microsoft.
denelon commentedon Jul 26, 2026
Issue summary
Current state — the framework is implemented:
--allow-rebootto opt in.ExpectedReturnCodesand handled gracefully: "reboot required to finish" is reported as a success with a warning (no automatic reboot), and a resume-after-reboot flow is available when reboots are allowed.Remaining gap (why this stays open):
.exeinstallers that don't honor a no-restart switch, an MSI that invokes a nested executable without passing the flag through, or updating a running dependency (e.g. VCRedist) that forces a reboot to complete.ExpectedReturnCodes), rather than something WinGet can universally force at the client level.Re-scoping:
Related
Drafted with the help of GitHub Copilot.
Kissaki commentedon Jul 27, 2026
I assume this refers to when the product installer triggers them, not when winget installs them as a dependency to the product installer?
Does winget handle the reboot stuff for dependencies it installs the same way as the product installers?
eldair commentedon Aug 17, 2026
EA App (ElectronicArts.EADesktop) also reboots without consent on update v13.768.7.6285-15019056 and it also removes the app. There was a similar issue I previously reported and was fixed but is probably related (microsoft/winget-pkgs#352972)
Here is event from event viewer:
eldair commentedon Sep 7, 2026
No updates on this? IT is a disaster, how can it be allowed for an app updated via cli tool without UI to execute reboot without any warning or consent?!