starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-03 21:25:34 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Please provide a way to delay updates #9338

New Issue
Closed
opened 2026-01-31 01:52:02 +00:00 by claunia · 41 comments
claunia commented 2026-01-31 01:52:02 +00:00
Owner
Copy Link

Originally created by @jr-lillard on GitHub (Jun 30, 2020).

Originally assigned to: @zadjii-msft on GitHub.

Description of the new feature/enhancement

I keep Windows Terminal open all the time. I also check for Microsoft Store updates daily. When an update to Windows Terminal is installed, it kills dozens of tabs I have open.

Proposed technical implementation details (optional)

It would be better for me to know that an update has been downloaded and is pending to be installed. I could then close all instances of Windows Terminal myself and when opening it the next time it would update before running. This is how Google Chrome works.

Originally created by @jr-lillard on GitHub (Jun 30, 2020). Originally assigned to: @zadjii-msft on GitHub. <!-- 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING: 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement. 2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement. 3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number). 4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement. 5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement. All good? Then proceed! --> # Description of the new feature/enhancement <!-- A clear and concise description of what the problem is that the new feature would solve. Describe why and how a user would use this new functionality (if applicable). --> I keep Windows Terminal open all the time. I also check for Microsoft Store updates daily. When an update to Windows Terminal is installed, it kills dozens of tabs I have open. # Proposed technical implementation details (optional) <!-- A clear and concise description of what you want to happen. --> It would be better for me to know that an update has been downloaded and is pending to be installed. I could then close all instances of Windows Terminal myself and when opening it the next time it would update before running. This is how Google Chrome works.
claunia added the In-PRTracking-External labels 2026-01-31 01:52:02 +00:00
claunia commented 2026-01-31 01:52:03 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jun 30, 2020):

It would be better for me to know that an update has been downloaded and is pending to be installed.

Terminal has no control over that. That is entirely dependent on how your settings are configured for the Store.

@WSLUser commented on GitHub (Jun 30, 2020): > It would be better for me to know that an update has been downloaded and is pending to be installed. Terminal has no control over that. That is entirely dependent on how your settings are configured for the Store.
claunia commented 2026-01-31 01:52:03 +00:00
Author
Owner
Copy Link

@jr-lillard commented on GitHub (Jun 30, 2020):

Fair enough. I had not looked into Store settings before. I always
clicked on Get Updates and it would download and install updates. I've
turned off the auto-updates setting and will see how it behaves. If it
checks for updates but does not install until I say so then this will
work. Thanks.

@jr-lillard commented on GitHub (Jun 30, 2020): Fair enough. I had not looked into Store settings before. I always clicked on Get Updates and it would download and install updates. I've turned off the auto-updates setting and will see how it behaves. If it checks for updates but does not install until I say so then this will work. Thanks.
claunia commented 2026-01-31 01:52:04 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jun 30, 2020):

So, I asked the application packaging and deployment team about this. Their answer was fairly direct: when you click get updates, you’re considered a “seeker”. People who actively seek updates get a different behavior than people who let the passive auto-updater update apps for them. Seekers’ applications are forcibly terminated, because they told the OS “no, give me updates, right now.”

@DHowett commented on GitHub (Jun 30, 2020): So, I asked the application packaging and deployment team about this. Their answer was fairly direct: when you click _get updates_, you’re considered a “seeker”. People who actively seek updates get a different behavior than people who let the passive auto-updater update apps for them. Seekers’ applications are forcibly terminated, because they told the OS “no, give me updates, right now.”
claunia commented 2026-01-31 01:52:04 +00:00
Author
Owner
Copy Link

@jr-lillard commented on GitHub (Jun 30, 2020):

Bummer. I don't suppose there's a way for Microsoft Store to simply show
me if updates are available then? I'm also thinking along the lines of
Windows Updates. I can check for updates and install them but the restart
doesn't happen without my permission.

@jr-lillard commented on GitHub (Jun 30, 2020): Bummer. I don't suppose there's a way for Microsoft Store to simply show me if updates are available then? I'm also thinking along the lines of Windows Updates. I can check for updates and install them but the restart doesn't happen without my permission.
claunia commented 2026-01-31 01:52:04 +00:00
Author
Owner
Copy Link

@electronic-dk commented on GitHub (Jun 30, 2020):

Probably something along the lines of how Edge, for example, handles the updates would be cool i.e. show that there's a new version available but not force restart the app right away. I understand that that's probably not the easiest issue to solve and there's probably no single solution that would satisfy everyone but maybe that's something the MS store could move to in the future.
That would probably be somewhat solved with the winget once it learns how to show the apps/packages that are ready to be updated.

@electronic-dk commented on GitHub (Jun 30, 2020): Probably something along the lines of how Edge, for example, handles the updates would be cool i.e. show that there's a new version available but not force restart the app right away. I understand that that's probably not the easiest issue to solve and there's probably no single solution that would satisfy everyone but maybe that's something the MS store could move to in the future. That would probably be somewhat solved with the winget once it learns how to show the apps/packages that are ready to be updated.
claunia commented 2026-01-31 01:52:05 +00:00
Author
Owner
Copy Link

@factormystic commented on GitHub (Jun 30, 2020):

So, I asked the application packaging and deployment team about this. Their answer was fairly direct: when you click get updates, you’re considered a “seeker”. People who actively seek updates get a different behavior than people who let the passive auto-updater update apps for them. Seekers’ applications are forcibly terminated, because they told the OS “no, give me updates, right now.”

Thanks for checking into this @DHowett and so if there's nothing that the Terminal team can do about this I guess that's that.

HOWEVER:

This response from them is ultra lame. Yeah, I'm clicking around to see what's up, or maybe because I want to see what's updated, or maybe because I know some other app got updated.

But what I'm saying with those clicks isn't "please kill my terminal instances, which close/secretly detach my various terminal panes, and the web server(s), logs tails, etc running inside of them, thus essentially resetting my active development environment from some other app, on some other virtual desktop".

To hear me say this and think "yeah, that's certainly what the user intended when they were clicking around the store app" is foolishness. Whoever is holding on to this foolishness on the store team needs to have their thinking updated.

What can we do to get this scenario into the store team mindset? Is there someone from that team we can get onto this thread? Is there someone we should complain to? Can you take this feedback and send it back to them?

Another lens here is, what will it take to make this into a pleasant experience instead of a disappointing experience? Certainly getting the store team to up their game would be nice, but if that's not going to happen then I wonder what else can be done.

For example, hypothetically, could each terminal instance record it's current pane layout, detach from running processes that it started, allow the store to kill it & bring it back (somehow), detect that this is what happened, restore its pane layout, then reattach each child process?

The thinking here is that the store can kill the app, but the damage is now avoided because everything is restored.

@factormystic commented on GitHub (Jun 30, 2020): > So, I asked the application packaging and deployment team about this. Their answer was fairly direct: when you click _get updates_, you’re considered a “seeker”. People who actively seek updates get a different behavior than people who let the passive auto-updater update apps for them. Seekers’ applications are forcibly terminated, because they told the OS “no, give me updates, right now.” Thanks for checking into this @DHowett and so if there's nothing that the Terminal team can do about this I guess that's that. HOWEVER: This response from them is _ultra lame_. Yeah, I'm clicking around to see what's up, or maybe because I want to see what's updated, or maybe because I know some other app got updated. But what I'm saying with those clicks **isn't** "please kill my terminal instances, which close/secretly detach my various terminal panes, and the web server(s), logs tails, etc running inside of them, thus essentially resetting my **active development environment** from **some other app**, on **some other virtual desktop**". To hear me say this and think "yeah, that's certainly what the user intended when they were clicking around the store app" is **foolishness**. Whoever is holding on to this foolishness on the store team needs to have their thinking updated. What can we do to get this scenario into the store team mindset? Is there someone from that team we can get onto this thread? Is there someone we should complain to? Can you take this feedback and send it back to them? ----- Another lens here is, what will it take to make this into a pleasant experience instead of a disappointing experience? Certainly getting the store team to up their game would be nice, but if that's not going to happen then I wonder what else can be done. For example, hypothetically, could each terminal instance record it's current pane layout, detach from running processes that it started, allow the store to kill it & bring it back (somehow), detect that this is what happened, restore its pane layout, then reattach each child process? The thinking here is that the store can kill the app, but the damage is now avoided because everything is restored.
claunia commented 2026-01-31 01:52:05 +00:00
Author
Owner
Copy Link

@WSLUser commented on GitHub (Jun 30, 2020):

Feedback Hub is the official way to communicate concerns about the Store to the Store team. I would say it's likely to be ignored but with the Store now being the only way to purchase products directly from MS, theres a higher than normal chance this feedback will get attention but not necessarily resolution.

@WSLUser commented on GitHub (Jun 30, 2020): Feedback Hub is the official way to communicate concerns about the Store to the Store team. I would say it's likely to be ignored but with the Store now being the only way to purchase products directly from MS, theres a higher than normal chance this feedback will get attention but not necessarily resolution.
claunia commented 2026-01-31 01:52:05 +00:00
Author
Owner
Copy Link

@qm2k commented on GitHub (Aug 21, 2020):

My issue was marked as duplicate so I will repeat my suggestion here: update the app, but keep the state. It would be really cool and different. At least on my system the subprocesses are not really getting killed, so I believe it must be technically possible to attach them back (e.g. add some intermediate process controlled through a pipe that survives).

And yes, I totally agree with @factormystic about the response that users somehow want this behaviour: it is superb lame and arrogant to claim this. It's worse than the Clippy was. In no system ever was my command-line session was terminated because the terminal package needed an update. Sooner or later it will happen while someone updates a mission-ciritical system remotely without tmux, or do a multi-month calculation or rendering, or mine/save bitcoins, and it will all be in the news.

@qm2k commented on GitHub (Aug 21, 2020): My issue was marked as duplicate so I will repeat my suggestion here: update the app, but keep the state. It would be really cool and different. At least on my system the subprocesses are not really getting killed, so I believe it must be technically possible to attach them back (e.g. add some intermediate process controlled through a pipe that survives). And yes, I totally agree with @factormystic about the response that users somehow want this behaviour: it is superb lame and arrogant to claim this. It's worse than the Clippy was. In no system ever was my command-line session was terminated because the terminal package needed an update. Sooner or later it will happen while someone updates a mission-ciritical system remotely without tmux, or do a multi-month calculation or rendering, or mine/save bitcoins, and it will all be in the news.
claunia commented 2026-01-31 01:52:06 +00:00
Author
Owner
Copy Link

@huoyaoyuan commented on GitHub (Sep 1, 2020):

People who actively seek updates get a different behavior than people who let the passive auto-updater update apps for them.

@DHowett I have to point out that the passive auto-update is still too aggressive for Terminal.
Yesterday night I left a long running task (~10h) in Terminal, and find it auto updated in about 5h. I'm not so angry because there are save points, but the update staggery is definitely unsuitable.

@huoyaoyuan commented on GitHub (Sep 1, 2020): > People who actively seek updates get a different behavior than people who let the passive auto-updater update apps for them. @DHowett I have to point out that the passive auto-update is still too aggressive for Terminal. Yesterday night I left a long running task (~10h) in Terminal, and find it auto updated in about 5h. I'm not so angry because there are save points, but the update staggery is definitely unsuitable.
claunia commented 2026-01-31 01:52:06 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 1, 2020):

Fair.

Given that we can’t change the store’s behavior, your best option is to extract the msixbundle like a ZIP file and run WindowsTerminal from inside it. It will never update, never change, never get terminated by the store, not be codesigned, not be trusted by your organization, and is completely unsupported but it works.

@DHowett commented on GitHub (Sep 1, 2020): Fair. Given that we can’t change the store’s behavior, your best option is to extract the msixbundle like a ZIP file and run WindowsTerminal from inside it. It will never update, never change, never get terminated by the store, not be codesigned, not be trusted by your organization, and is completely unsupported but _it works._
claunia commented 2026-01-31 01:52:06 +00:00
Author
Owner
Copy Link

@jsejcksn commented on GitHub (Sep 1, 2020):

FWIW, I recently saw that the store version of Terminal has implemented a modal confirmation dialog before being closed by the store. No screenshot to post. Maybe someone else can link to an update about the new behavior.

@jsejcksn commented on GitHub (Sep 1, 2020): FWIW, I recently saw that the store version of Terminal has implemented a modal confirmation dialog before being closed by the store. No screenshot to post. Maybe someone else can link to an update about the new behavior.
claunia commented 2026-01-31 01:52:06 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 1, 2020):

Unfortunately, the store simply terminates Terminal even if we sink the close message. We’ve tried. 😄

@DHowett commented on GitHub (Sep 1, 2020): Unfortunately, the store simply terminates Terminal even if we sink the close message. We’ve tried. 😄
claunia commented 2026-01-31 01:52:07 +00:00
Author
Owner
Copy Link

@brobichaud commented on GitHub (Sep 24, 2020):

Simply blaming this on the store isn't really productive. Pointing out it's a limitation of store apps sure, but perhaps the line of thought needs to move towards options, such as:

  1. Should terminal NOT be a store app?
  2. Should terminal fully persist its state?

The second option seems ideal to me. A bunch of work for sure but could solidly address the issue. If it persisted state such that when terminal is restarted after an update it brings you back to exactly where you were with all command history, scroll position and all those other little nuances retained. The one thing it probably can't fix is if a tab was in the middle of some long running operation, not sure how to address that.

The current behavior is quite infuriating and makes me not want to use terminal. It's almost as bad as Windows updates auto-magically losing all context of everything I had open.

@brobichaud commented on GitHub (Sep 24, 2020): Simply blaming this on the store isn't really productive. Pointing out it's a limitation of store apps sure, but perhaps the line of thought needs to move towards options, such as: 1. Should terminal NOT be a store app? 2. Should terminal fully persist its state? The second option seems ideal to me. A bunch of work for sure but could solidly address the issue. If it persisted state such that when terminal is restarted after an update it brings you back to exactly where you were with all command history, scroll position and all those other little nuances retained. The one thing it probably can't fix is if a tab was in the middle of some long running operation, not sure how to address that. The current behavior is quite infuriating and makes me not want to use terminal. It's almost as bad as Windows updates auto-magically losing all context of everything I had open.
claunia commented 2026-01-31 01:52:07 +00:00
Author
Owner
Copy Link

@mg-christian-esser commented on GitHub (Sep 25, 2020):

  1. Should terminal NOT be a store app?

I think providing a proper out of store option is a reasonable request.

  1. Should terminal fully persist its state?

The second option seems ideal to me. A bunch of work for sure but could solidly address the issue. If it persisted state such that when terminal is restarted after an update it brings you back to exactly where you were with all command history, scroll position and all those other little nuances retained. The one thing it probably can't fix is if a tab was in the middle of some long running operation, not sure how to address that.

Trying to persist state is pretty much impossible for any reasonable complex setup, even if you disregard running processes. Attempts to do so just rubs it in even harder in my experience (like the Windows Update automatic reboot starting up programs again but the state within the program is completely lost)

@mg-christian-esser commented on GitHub (Sep 25, 2020): > 1. Should terminal NOT be a store app? I think providing a proper out of store option is a reasonable request. > 2. Should terminal fully persist its state? > > The second option seems ideal to me. A bunch of work for sure but could solidly address the issue. If it persisted state such that when terminal is restarted after an update it brings you back to exactly where you were with all command history, scroll position and all those other little nuances retained. The one thing it probably can't fix is if a tab was in the middle of some long running operation, not sure how to address that. Trying to persist state is pretty much impossible for any reasonable complex setup, even if you disregard running processes. Attempts to do so just rubs it in even harder in my experience (like the Windows Update automatic reboot starting up programs again but the state within the program is completely lost)
claunia commented 2026-01-31 01:52:07 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 25, 2020):

Hey for the record, there's a bunch more discussion about restoring terminal state in #961, so maybe we should move the discussion there.

@zadjii-msft commented on GitHub (Sep 25, 2020): Hey for the record, there's a bunch more discussion about restoring terminal state in #961, so maybe we should move the discussion there.
claunia commented 2026-01-31 01:52:07 +00:00
Author
Owner
Copy Link

@ckovey commented on GitHub (Sep 25, 2020):

Restoring state would be cool, but one other issue I believe for this thread are processes that listen/don't terminate when updates happen and Terminal itself gets closed

For example a Laravel app I am working on. I will have 2 tabs in Terminal, one for running commands like git or scaffolding, and another that is split into 3 panes to: 1) run the local dev server php artisan serve, 2) run webpack and compile Sass, and 3) one to compile TypeScript

These 3 are running until I ctrl-c them, listening for web requests or watching file changes to automatically compile assets for web.

When an update happens like yesterday for 1.3.2651.0 my Terminal window goes away but all of those processes are still running and the only way to stop them is killing via task manager. At which point something like #961 would be nice to restart the 3 :)

All of my tabs/panes are running WSL Ubuntu 18.04

@ckovey commented on GitHub (Sep 25, 2020): Restoring state would be cool, but one other issue I believe for this thread are processes that listen/don't terminate when updates happen and Terminal itself gets closed For example a Laravel app I am working on. I will have 2 tabs in Terminal, one for running commands like git or scaffolding, and another that is split into 3 panes to: 1) run the local dev server `php artisan serve`, 2) run webpack and compile Sass, and 3) one to compile TypeScript These 3 are running until I ctrl-c them, listening for web requests or watching file changes to automatically compile assets for web. When an update happens like yesterday for 1.3.2651.0 my Terminal window goes away but all of those processes are still running and the only way to stop them is killing via task manager. At which point something like #961 would be nice to restart the 3 :) All of my tabs/panes are running WSL Ubuntu 18.04
claunia commented 2026-01-31 01:52:08 +00:00
Author
Owner
Copy Link

@brobichaud commented on GitHub (Sep 25, 2020):

  1. Should terminal NOT be a store app?

I think providing a proper out of store option is a reasonable request.

It definitely feels like an easier option than restoring state. Would it be possible to continue offering terminal as a store app but have a side channel that offers it as a simple download for those that want to control the update process?

@brobichaud commented on GitHub (Sep 25, 2020): > > 1. Should terminal NOT be a store app? > > I think providing a proper out of store option is a reasonable request. It definitely feels like an easier option than restoring state. Would it be possible to continue offering terminal as a store app but have a side channel that offers it as a simple download for those that want to control the update process?
claunia commented 2026-01-31 01:52:08 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Sep 25, 2020):

have a side channel that offers it as a simple download for those that want to control the update process?

Maybe something like winget?

@zadjii-msft commented on GitHub (Sep 25, 2020): > have a side channel that offers it as a simple download for those that want to control the update process? Maybe something like `winget`?
claunia commented 2026-01-31 01:52:08 +00:00
Author
Owner
Copy Link

@dlong500 commented on GitHub (Nov 21, 2020):

  1. Should terminal NOT be a store app?

I think providing a proper out of store option is a reasonable request.

It definitely feels like an easier option than restoring state. Would it be possible to continue offering terminal as a store app but have a side channel that offers it as a simple download for those that want to control the update process?

I've never been keen on using the store for a variety of reasons, and this type of situation just confirms my frame of mind. Auto-terminating without at least having to confirm the shutdown (with an option to cancel the update) is just crazy. It seems completely reasonable to offer a more admin/developer friendly option for installation via something like winget where you can still check for updates without having to close all terminal windows before checking out of fear everything will get shut down.

It's just completely unintuitive behavior the way it is right now. We should be able to check for updates manually or automatically (with notifications) but still get to decide when the update actually occurs. And we should be able to do this in an officially supported way. Sorry to sound demanding, and I understand that the terminal team isn't in control of the current behavior (due to the deployment via the store), but not terminating an app when an update is published has been standard practice for developers for a long time.

@dlong500 commented on GitHub (Nov 21, 2020): > > > 1. Should terminal NOT be a store app? > > > > > > I think providing a proper out of store option is a reasonable request. > > It definitely feels like an easier option than restoring state. Would it be possible to continue offering terminal as a store app but have a side channel that offers it as a simple download for those that want to control the update process? I've never been keen on using the store for a variety of reasons, and this type of situation just confirms my frame of mind. Auto-terminating without at least having to confirm the shutdown (with an option to cancel the update) is just crazy. It seems completely reasonable to offer a more admin/developer friendly option for installation via something like winget where you can still check for updates without having to close all terminal windows before checking out of fear everything will get shut down. It's just completely unintuitive behavior the way it is right now. We should be able to check for updates manually or automatically (with notifications) but still get to decide when the update actually occurs. And we should be able to do this in an officially supported way. Sorry to sound demanding, and I understand that the terminal team isn't in control of the current behavior (due to the deployment via the store), but not terminating an app when an update is published has been standard practice for developers for a long time.
claunia commented 2026-01-31 01:52:09 +00:00
Author
Owner
Copy Link

@mkahvi commented on GitHub (Dec 4, 2020):

I just updated another windows store app and the update process explicitly paused saying it can't update the app while it's running without user intervention. Clearly windows store has support for the feature needed for this.

@mkahvi commented on GitHub (Dec 4, 2020): I just updated another windows store app and the update process explicitly paused saying it can't update the app while it's running without user intervention. Clearly windows store has support for the feature needed for this.
claunia commented 2026-01-31 01:52:09 +00:00
Author
Owner
Copy Link

@jessey-git commented on GitHub (Jul 15, 2021):

This is also a problem with winget. If you use winget and attempt to upgrade the terminal application, well, it never completes since the terminal itself will be killed in the middle of update :) This makes it difficult to use Terminal as the only terminal...

@jessey-git commented on GitHub (Jul 15, 2021): This is also a problem with `winget`. If you use `winget` and attempt to upgrade the terminal application, well, it never completes since the terminal itself will be killed in the middle of update :) This makes it difficult to use Terminal as the only terminal...
claunia commented 2026-01-31 01:52:09 +00:00
Author
Owner
Copy Link

@GPHemsley-RELX commented on GitHub (Oct 7, 2021):

Coming back to Terminal not running is how I find out that there is a new set of beautiful release notes available to read.

@GPHemsley-RELX commented on GitHub (Oct 7, 2021): Coming back to Terminal not running is how I find out that there is a new set of beautiful release notes available to read.
claunia commented 2026-01-31 01:52:10 +00:00
Author
Owner
Copy Link

@brobichaud commented on GitHub (Oct 7, 2021):

Yeah it really does significantly erode any happiness about a new release. I can't tell you how many times I've wanted to toss terminal aside and go back to simpler times for this one specific problem.

@brobichaud commented on GitHub (Oct 7, 2021): Yeah it really does significantly erode any happiness about a new release. I can't tell you how many times I've wanted to toss terminal aside and go back to simpler times for this one specific problem.
claunia commented 2026-01-31 01:52:10 +00:00
Author
Owner
Copy Link

@BouwenMA commented on GitHub (Oct 21, 2021):

My experience has not matched many prior listed here in this issue: For me the update process also seems to kill the actual PowerShell processes.... No warnings/prompts... And it also does so without me actively selecting "Get updates" from the store page. I'll sometimes come back the next morning looking to see output from scripts that ran overnight, only to see the window/sessions closed... For this reason alone there is no way I'd ever be able to use the new Terminal for production use.... a crying shame as it is very nice and the team has been doing excellent work!....

According to "Update Store-published apps from your code", it would appear that there are options possibly from a Windows Terminal aspect to handle these:?
https://docs.microsoft.com/en-us/windows/msix/store-developer-package-update

Fine-controlled updates

For developers who want to have a completely customized experience, additional APIs are provided which enable more control over the update process. The platform enables you to do the following:

-Get progress events on an individual package download or on the whole update.
-Apply updates at the user's and app's convenience rather than one or the other.
Developers are able to download updates in the background (while app is in use) then request the user install updates, if they decline, you can simply disable capabilities affected by the update if you choose.

Alternately I'd also vote to ask for option to make Windows Terminal not tied only to the Windows Store, with supported options for alternate/manual installs. PowerShell for example has many install options, with one of them being from the store... Something I'm not likely to try myself for PowerShell either after seeing the store update behavior here for this. (I appreciate DHowett's post from Sept last year in this thread for an unsupported option - if only I could use that on Win Server 2016 ;-) )...

@BouwenMA commented on GitHub (Oct 21, 2021): My experience has not matched many prior listed here in this issue: For me the update process also seems to kill the actual PowerShell processes.... No warnings/prompts... And it also does so _without me actively selecting "Get updates" from the store page_. I'll sometimes come back the next morning looking to see output from scripts that ran overnight, only to see the window/sessions closed... For this reason alone there is no way I'd ever be able to use the new Terminal for production use.... a crying shame as it is very nice and the team has been doing excellent work!.... According to "Update Store-published apps from your code", it would appear that there are options possibly from a Windows Terminal aspect to handle these:? https://docs.microsoft.com/en-us/windows/msix/store-developer-package-update > **Fine-controlled updates** > > For developers who want to have a completely customized experience, additional APIs are provided which enable more control over the update process. The platform enables you to do the following: > > -Get progress events on an individual package download or on the whole update. > -Apply updates at the user's and app's convenience rather than one or the other. > Developers are able to download updates in the background (while app is in use) then request the user install updates, if they decline, you can simply disable capabilities affected by the update if you choose. Alternately I'd also vote to ask for option to make Windows Terminal not tied only to the Windows Store, with _supported options_ for alternate/manual installs. PowerShell for example has many install options, with one of them being from the store... Something I'm not likely to try myself for PowerShell either after seeing the store update behavior here for this. (I appreciate DHowett's post from Sept last year in this thread for an unsupported option - if only I could use that on Win Server 2016 ;-) )...
claunia commented 2026-01-31 01:52:10 +00:00
Author
Owner
Copy Link

@jessey-git commented on GitHub (Oct 21, 2021):

Here's what I see today - using 1.12 as a test vehicle

Store with auto-updating off

  • I manually downloaded the update and then the Store showed an explicit "Update" button
  • Once I clicked that button my existing Terminal windows were exited

winget

Found Windows Terminal Preview [Microsoft.WindowsTerminalPreview] Version 1.12.2931.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Starting package install...

Successfully installed. Restart the application to complete the upgrade.

I'm not sure what happens if you use Store with auto-update turned on. So this is a bit better than before but probably still precarious if Store auto-update unconditionally kills them.

@jessey-git commented on GitHub (Oct 21, 2021): Here's what I see today - using 1.12 as a test vehicle Store with auto-updating off - I manually downloaded the update and then the Store showed an explicit "Update" button - Once I clicked that button my existing Terminal windows were exited `winget` ``` Found Windows Terminal Preview [Microsoft.WindowsTerminalPreview] Version 1.12.2931.0 This application is licensed to you by its owner. Microsoft is not responsible for, nor does it grant any licenses to, third-party packages. Successfully verified installer hash Starting package install... Successfully installed. Restart the application to complete the upgrade. ``` I'm not sure what happens if you use Store with auto-update turned on. So this is a bit better than before but probably still precarious if Store auto-update unconditionally kills them.
claunia commented 2026-01-31 01:52:11 +00:00
Author
Owner
Copy Link

@mkahvi commented on GitHub (Oct 21, 2021):

Store autoupdate has not been autokilling terminal for me for a while, but I've also been avoiding clicking the get all updates. Most apps there however wait for me to close things out before updating even when I specifically tell it to update them.

@mkahvi commented on GitHub (Oct 21, 2021): Store autoupdate has not been autokilling terminal for me for a while, but I've also been avoiding clicking the get all updates. Most apps there however wait for me to close things out before updating even when I specifically tell it to update them.
claunia commented 2026-01-31 01:52:11 +00:00
Author
Owner
Copy Link

@chrystalis commented on GitHub (Nov 2, 2021):

I apparently had store auto-updates turned on somehow, though I don't remember ever doing so. My terminals have been unceremoniously killed a couple of times in the past month, which I had not experienced previously. This is really unpleasant because it leaves a bunch of WSL1 & WSL2 Ubuntu processes orphaned; I added additional details in #9914 (comment).

@chrystalis commented on GitHub (Nov 2, 2021): I apparently had store auto-updates turned on somehow, though I don't remember ever doing so. My terminals have been unceremoniously killed a couple of times in the past month, which I had not experienced previously. This is really unpleasant because it leaves a bunch of WSL1 & WSL2 Ubuntu processes orphaned; I added additional details in #9914 ([comment](https://github.com/microsoft/terminal/issues/9914#issuecomment-957048413)).
claunia commented 2026-01-31 01:52:11 +00:00
Author
Owner
Copy Link

@mailinglists35 commented on GitHub (Feb 6, 2022):

Feedback Hub issue for Microsot Store to stop ending running apps during auto update:

https://aka.ms/AAfnjsj

@mailinglists35 commented on GitHub (Feb 6, 2022): Feedback Hub issue for Microsot Store to stop ending running apps during auto update: https://aka.ms/AAfnjsj
claunia commented 2026-01-31 01:52:12 +00:00
Author
Owner
Copy Link

@mailinglists35 commented on GitHub (Feb 7, 2022):

I wonder if unchecking "Terminate" permission to SYSTEM and LogonSessionID* users would prevent MS Store from killing Terminal. This would save us from altering MS Store behaviour or running Terminal from a manually downloaded file.

You would have to do this every time you relaunch Terminal, but if you are like me, this running terminal will be alive for long.

We'll see on the next update, I have unchecked it for both, using Process Hacker.
PS: just in case I've denied the permission for my own user as well.
PS2: for extra paranoia I've added Deny Terminate to Everyone.

image

@mailinglists35 commented on GitHub (Feb 7, 2022): I wonder if unchecking "Terminate" permission to SYSTEM and LogonSessionID* users would prevent MS Store from killing Terminal. This would save us from altering MS Store behaviour or running Terminal from a manually downloaded file. You would have to do this every time you relaunch Terminal, but if you are like me, this running terminal will be alive for long. We'll see on the next update, I have unchecked it for both, using Process Hacker. PS: just in case I've denied the permission for my own user as well. PS2: for extra paranoia I've added Deny Terminate to Everyone. ![image](https://user-images.githubusercontent.com/2054302/152845168-5f2f826a-c260-4a72-974e-8100f6c8255c.png)
claunia commented 2026-01-31 01:52:12 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 6, 2022):

Hey all,

After a long series of mails with the Store team, we've managed to get some updates to this experience. They should be rolling out in Windows 11 Insider Preview Build 25131

Improved app updates: We improved updates when clicking Update buttons in the Microsoft Store. We’ll skip over apps that you have open, so you don’t lose any important work. You can manually update the apps later.

image

This change isn't exclusive to the Terminal, it should be a better experience for all apps now. There are likely more improvements planned in the future in this space, but this initial update should greatly improve the experience. Thanks everyone for their patience here!

@zadjii-msft commented on GitHub (Jun 6, 2022): Hey all, After a long series of mails with the Store team, we've managed to get some updates to this experience. They should be rolling out in [Windows 11 Insider Preview Build 25131](https://blogs.windows.com/windows-insider/2022/06/02/announcing-windows-11-insider-preview-build-25131/) > **Improved app updates**: We improved updates when clicking Update buttons in the Microsoft Store. We’ll skip over apps that you have open, so you don’t lose any important work. You can manually update the apps later. ![image](https://user-images.githubusercontent.com/18356694/172153629-e8617e16-07cb-46ce-8d1f-078fa50c811d.png) This change isn't exclusive to the Terminal, it should be a better experience for _all_ apps now. There are likely more improvements planned in the future in this space, but this initial update should greatly improve the experience. Thanks everyone for their patience here!
claunia commented 2026-01-31 01:52:12 +00:00
Author
Owner
Copy Link

@vbrozik commented on GitHub (Jun 6, 2022):

@zadjii-msft Great, thank you a lot! Is the app update improvement going to be backported to Windows 10? I think many enterprises will be using Windows 10 for a long time.

@vbrozik commented on GitHub (Jun 6, 2022): @zadjii-msft Great, thank you a lot! Is the app update improvement going to be backported to Windows 10? I think many enterprises will be using Windows 10 for a long time.
claunia commented 2026-01-31 01:52:12 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jun 6, 2022):

Is the app update improvement going to be backported to Windows 10

I honestly can't comment on the Store's plans because I simply don't know them. From prior experience, I would guess that this isn't something that'd come back to Windows 10, but don't take that as a definitive statement of any sort. I believe this is tied to a variety of changes to the platform code, so I don't think it's as trivial as pushing a Store UI update downlevel. (Again, speaking from hearsay and not expertise in how the Store works)

@zadjii-msft commented on GitHub (Jun 6, 2022): > Is the app update improvement going to be backported to Windows 10 I honestly can't comment on the Store's plans because I simply don't know them. From prior experience, I would _guess_ that this isn't something that'd come back to Windows 10, but don't take that as a definitive statement of any sort. I believe this is tied to a variety of changes to the platform code, so I don't think it's as trivial as pushing a Store UI update downlevel. (Again, speaking from hearsay and not expertise in how the Store works)
claunia commented 2026-01-31 01:52:13 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 3, 2023):

Sorry to necro this thread folks. Ultimately, the aforementioned fix didn't end up shipping outside of Insiders, because it had ~ u n i n t e n d e d ~ side effects. That's okay! That's the point of Insiders, to help iterate on designs.

Instead, a different path was pursued in the platform. I believe it was shipped in the Insiders SDK today, but I haven't confirmed which build exactly. Basically, we'll need to add a new property to our manifest to let the Store know "please don't force-kill me for updates".

I'm reopening this thread for now. When the next official SDK version is out, we'll need to add a new uap16 property to our manifest, and that should fix this issue for users on the latest Windows 11 bits.

It's not the most ideal solution in the world, but I'm happy to have any solution at this point.

The large volume of community feedback was really helpful in getting this prioritized with the rest of the teams involved here, so for that - I thank all of you ☺️

@zadjii-msft commented on GitHub (May 3, 2023): Sorry to necro this thread folks. Ultimately, the aforementioned fix didn't end up shipping outside of Insiders, because it had ~ u n i n t e n d e d ~ side effects. That's okay! That's the point of Insiders, to help iterate on designs. Instead, a different path was pursued in the platform. I believe it was shipped in the Insiders SDK today, but I haven't confirmed which build exactly. Basically, we'll need to add a new property to our manifest to let the Store know "please don't force-kill me for updates". I'm reopening this thread for now. When the next official SDK version is out, we'll need to add a new `uap16` property to our manifest, and that should fix this issue for users on the latest Windows 11 bits. It's not the _most_ ideal solution in the world, but I'm happy to have _any_ solution at this point. The _large_ volume of community feedback was really helpful in getting this prioritized with the rest of the teams involved here, so for that - I thank all of you ☺️
claunia commented 2026-01-31 01:52:13 +00:00
Author
Owner
Copy Link

@mikehearn commented on GitHub (May 19, 2023):

@zadjii-msft For those of us who would like to adopt the same fix in other apps, could you let us know what this uwp16 property is going to be? Unfortunately AppxManifest.xml changes aren't centrally logged or announced anywhere so the only other alternative is to poll the docs looking for new uap16 namespace items.

@mikehearn commented on GitHub (May 19, 2023): @zadjii-msft For those of us who would like to adopt the same fix in other apps, could you let us know what this uwp16 property is going to be? Unfortunately AppxManifest.xml changes aren't centrally logged or announced anywhere so the only other alternative is to poll the docs looking for new uap16 namespace items.
claunia commented 2026-01-31 01:52:13 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 19, 2023):

Would you mind if I wait till it's out of the Preview SDK? As we've seen in the past (literally in this thread), preview features sometimes have to be backed out before release, and I don't want to promise something to 3p devs that might not land. I'd be less reluctant if it was some preview feature our team owned, but I'd rather err on the side of caution with another team's stuff.

I'm setting up some time (soonTM, I'll be OOF for June) to test this out in the Terminal with the Preview SDK and the folks who wrote the API - when I do, I'll surely link the dev branch here if you're really curious

@zadjii-msft commented on GitHub (May 19, 2023): Would you mind if I wait till it's out of the Preview SDK? As we've seen in the past _(literally in this thread)_, preview features sometimes have to be backed out before release, and I don't want to promise something to 3p devs that might _not_ land. I'd be less reluctant if it was some preview feature our team owned, but I'd rather err on the side of caution with another team's stuff. I'm setting up some time (soon<sup>TM</sup>, I'll be OOF for June) to test this out in the Terminal with the Preview SDK and the folks who wrote the API - when I do, I'll surely link the dev branch here if you're really curious
claunia commented 2026-01-31 01:52:13 +00:00
Author
Owner
Copy Link

@mikehearn commented on GitHub (May 19, 2023):

@zadjii-msft Of course, that's perfectly understandable. I mostly just didn't want to forget this thread :-)

@mikehearn commented on GitHub (May 19, 2023): @zadjii-msft Of course, that's perfectly understandable. I mostly just didn't want to forget this thread :-)
claunia commented 2026-01-31 01:52:14 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 31, 2023):

Spoke more with that team yesterday. They said it's cool to share.

<Package
  ...
  xmlns:uap17="http://schemas.microsoft.com/appx/manifest/uap/windows10/17"
  IgnorableNamespaces="uap uap17 uap16 mp">

  <Properties>
    <uap17:UpdateWhileInUse>defer</uap17:UpdateWhileInUse>
  </Properties>
  
</Package>

That property should be in the current Insiders preview SDK. For reasons we (the Terminal) can't use that till it gets released as part of the stable SDK, later this year.

@zadjii-msft commented on GitHub (May 31, 2023): Spoke more with that team yesterday. They said it's cool to share. ```xml <Package ... xmlns:uap17="http://schemas.microsoft.com/appx/manifest/uap/windows10/17" IgnorableNamespaces="uap uap17 uap16 mp"> <Properties> <uap17:UpdateWhileInUse>defer</uap17:UpdateWhileInUse> </Properties> </Package> ``` That property should be in the current Insiders preview SDK. For _reasons_ we (the Terminal) can't use that till it gets released as part of the stable SDK, later this year.
claunia commented 2026-01-31 01:52:14 +00:00
Author
Owner
Copy Link

@mikehearn commented on GitHub (May 31, 2023):

Thanks man! When you say "insiders preview SDK", I'm not quite sure what that means. I know what Windows Insiders is (a preview build you can opt in to), but don't understand the relation between the SDK and Windows here. My company makes a tool that builds MSIX files and AppxManifests itself, without using any MS tooling. We can start emitting this XML tomorrow, no problem, and maybe we should. The real question is when Windows itself will start to recognize it.

@mikehearn commented on GitHub (May 31, 2023): Thanks man! When you say "insiders preview SDK", I'm not quite sure what that means. I know what Windows Insiders is (a preview build you can opt in to), but don't understand the relation between the SDK and Windows here. My company makes a tool that builds MSIX files and AppxManifests itself, without using any MS tooling. We can start emitting this XML tomorrow, no problem, and maybe we should. The real question is when Windows itself will start to recognize it.
claunia commented 2026-01-31 01:52:14 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (May 31, 2023):

Ah, by "Insiders Preview SDK", I mean this: https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewSDK

Appxmanifest entries are a little weird sometimes. The tooling needs to be updated to know about this new manifest entry, separately from the OS actually supporting the feature. So the tooling will reject this flag if you try to build it using an SDK version before at least 25362. That's half the picture. The other half is the OS itself needs to recognize this flag, which again I think is only in builds >=25362. The Insiders -> Stable build numbers are a little weird these days, so I don't know what OS version that will ultimately become when it's officially released in fall. 22000.something, probably.

If you're building msix's without the official tooling, then I dunno how your tooling will react to "unrecognized" properties. I know the version from the SDK will explicitly reject things it doesn't know about, hence why we can't just add it to the Terminal today 😕

@zadjii-msft commented on GitHub (May 31, 2023): Ah, by "Insiders Preview SDK", I mean this: https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewSDK Appxmanifest entries are a little weird sometimes. The tooling needs to be updated to know about this new manifest entry, separately from the OS actually supporting the feature. So the tooling will reject this flag if you try to build it using an SDK version before at least 25362. That's half the picture. The other half is the OS itself needs to recognize this flag, which again I think is only in builds >=25362. The Insiders -> Stable build numbers are a little weird these days, so I don't know what OS version that will ultimately become when it's officially released in fall. `22000.something`, probably. If you're building msix's without the official tooling, then I dunno how your tooling will react to "unrecognized" properties. I know the version from the SDK will explicitly reject things it doesn't know about, hence why we can't just add it to the Terminal today 😕
claunia commented 2026-01-31 01:52:14 +00:00
Author
Owner
Copy Link

@mikehearn commented on GitHub (May 31, 2023):

Got it, thanks. Conveyor (see https://hydraulic.dev/) uses the official AppxManifest XSD schemas to validate, so I guess we'd need to patch those schemas or wait until a new set is released. It probably makes sense to start using it immediately, as people don't rebuild their apps instantly.

BTW, do you know why it's optional? What's the scenario that breaks if everyone is opted into this? I'm head scratching trying to think of when you'd want the store to kill the app whilst it's in use, and I can't come up with one but clearly something went wrong with the first attempt and there's a reason it's now optional. I worry if we opt in our users automatically, we'll hit the same issue.

@mikehearn commented on GitHub (May 31, 2023): Got it, thanks. Conveyor (see https://hydraulic.dev/) uses the official AppxManifest XSD schemas to validate, so I guess we'd need to patch those schemas or wait until a new set is released. It probably makes sense to start using it immediately, as people don't rebuild their apps instantly. BTW, do you know why it's optional? What's the scenario that breaks if everyone is opted into this? I'm head scratching trying to think of when you'd want the store to kill the app whilst it's in use, and I can't come up with one but clearly something went wrong with the first attempt and there's a reason it's now optional. I worry if we opt in our users automatically, we'll hit the same issue.
claunia commented 2026-01-31 01:52:14 +00:00
Author
Owner
Copy Link

@mikehearn commented on GitHub (Dec 2, 2023):

@zadjii-msft Looks like we're nearly there. I'm trying to work out what versions of Windows 11 support UAP17 and not having much luck. The PR says it shipped in the September 2023 "OS release". As far as I can tell UAP17 (and therefore this fix) requires build >=25936, but the latest version of Win11 available is 22631.2715

So is this still stuck in insiders/preview mode?

@mikehearn commented on GitHub (Dec 2, 2023): @zadjii-msft Looks like we're nearly there. I'm trying to work out what versions of Windows 11 support UAP17 and not having much luck. The PR says it shipped in the September 2023 "OS release". As far as I can tell UAP17 (and therefore this fix) requires build >=25936, but the latest version of Win11 available is 22631.2715 So is this still stuck in insiders/preview mode?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label In-PR Tracking-External
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#9338
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?