Repository: microsoft/terminal (language: cpp)

Issue:
Please provide a way to delay updates
<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

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.



Discussion / hints:
> 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. 
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.

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.”
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.

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.
> 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.
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.
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.
> 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.
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._
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.
Unfortunately, the store simply terminates Terminal even if we sink the close message. We’ve tried. 😄 
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.
> 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)
Hey for the record, there's a bunch more discussion about restoring terminal state in #961, so maybe we should move the discussion there.
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
> > 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?
> have a side channel that offers it as a simple download for those that want to control the update process?

Maybe something like `winget`?
> > > 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.
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.
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...
Coming back to Terminal not running is how I find out that there is a new set of beautiful release notes available to read.
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.
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 ;-) )...
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.
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.
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)).
Feedback Hub issue for Microsot Store to stop ending running apps during auto update:

https://aka.ms/AAfnjsj

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)

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!
@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. 
> 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)
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 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.
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
@zadjii-msft Of course, that's perfectly understandable. I mostly just didn't want to forget this thread :-) 
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. 
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.
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 😕 
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.

Fix patch:
diff --git a/src/cascadia/CascadiaPackage/Package-Can.appxmanifest b/src/cascadia/CascadiaPackage/Package-Can.appxmanifest
index 04c7960ce95..66564e799ff 100644
--- a/src/cascadia/CascadiaPackage/Package-Can.appxmanifest
+++ b/src/cascadia/CascadiaPackage/Package-Can.appxmanifest
@@ -8,13 +8,14 @@
   xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3"
   xmlns:uap4="http://schemas.microsoft.com/appx/manifest/uap/windows10/4"
   xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5"
+  xmlns:uap17="http://schemas.microsoft.com/appx/manifest/uap/windows10/17"
   xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10"
   xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4"
   xmlns:desktop5="http://schemas.microsoft.com/appx/manifest/desktop/windows10/5"
   xmlns:desktop6="http://schemas.microsoft.com/appx/manifest/desktop/windows10/6"
   xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
   xmlns:virtualization="http://schemas.microsoft.com/appx/manifest/virtualization/windows10"
-  IgnorableNamespaces="uap mp rescap uap3 desktop6 virtualization">
+  IgnorableNamespaces="uap mp rescap uap3 uap17 desktop6 virtualization">
 
   <Identity
     Name="Microsoft.WindowsTerminalCanary"
@@ -33,6 +34,7 @@
         <virtualization:ExcludedKey>HKEY_CURRENT_USER\Console\%%Startup</virtualization:ExcludedKey>
       </virtualization:ExcludedKeys>
     </virtualization:RegistryWriteVirtualization>
+    <uap17:UpdateWhileInUse>defer</uap17:UpdateWhileInUse>
   </Properties>
 
   <Dependencies>
diff --git a/src/cascadia/CascadiaPackage/Package-Dev.appxmanifest b/src/cascadia/CascadiaPackage/Package-Dev.appxmanifest
index 4a0735bb206..d8ceefaeef6 100644
--- a/src/cascadia/CascadiaPackage/Package-Dev.appxmanifest
+++ b/src/cascadia/CascadiaPackage/Package-Dev.appxmanifest
@@ -7,6 +7,7 @@
   xmlns:uap="http://schemas.microsoft.com/appx/manifest/uap/windows10"
   xmlns:uap3="http://schemas.microsoft.com/appx/manifest/uap/windows10/3"
   xmlns:uap4="http://schemas.microsoft.com/appx/manifest/uap/windows10/4"
+  xmlns:uap17="http://schemas.microsoft.com/appx/manifest/uap/windows10/17"
   xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10"
   xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4"
   xmlns:desktop5="http://schemas.microsoft.com/appx/manifest/desktop/windows10/5"
@@ -14,7 +15,7 @@
   xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
   xmlns:virtualization="http://schemas.microsoft.com/appx/manifest/virtualization/windows10"
   xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5"
-  IgnorableNamespaces="uap mp rescap uap3 desktop6 virtualization">
+  IgnorableNamespaces="uap mp rescap uap3 uap17 desktop6 virtualization">
 
   <Identity
     Name="WindowsTerminalDev"
@@ -33,6 +34,7 @@
         <virtualization:ExcludedKey>HKEY_CURRENT_USER\Console\%%Startup</virtualization:ExcludedKey>
       </virtualization:ExcludedKeys>
     </virtualization:RegistryWriteVirtualization>
+    <uap17:UpdateWhileInUse>defer</uap17:UpdateWhileInUse>
   </Properties>
 
   <Dependencies>
diff --git a/src/cascadia/CascadiaPackage/Package-Pre.appxmanifest b/src/cascadia/CascadiaPackage/Package-Pre.appxmanifest
index 98fb12b9455..3a7bf26e0f7 100644
--- a/src/cascadia/CascadiaPackage/Package-Pre.appxmanifest
+++ b/src/cascadia/CascadiaPackage/Package-Pre.appxmanifest
@@ -9,13 +9,14 @@
   xmlns:uap4="http://schemas.microsoft.com/appx/manifest/uap/windows10/4"
   xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5"
   xmlns:uap7="http://schemas.microsoft.com/appx/manifest/uap/windows10/7"
+  xmlns:uap17="http://schemas.microsoft.com/appx/manifest/uap/windows10/17"
   xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10"
   xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4"
   xmlns:desktop5="http://schemas.microsoft.com/appx/manifest/desktop/windows10/5"
   xmlns:desktop6="http://schemas.microsoft.com/appx/manifest/desktop/windows10/6"
   xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
   xmlns:virtualization="http://schemas.microsoft.com/appx/manifest/virtualization/windows10"
-  IgnorableNamespaces="uap mp rescap uap3 desktop6 virtualization">
+  IgnorableNamespaces="uap mp rescap uap3 uap17 desktop6 virtualization">
 
   <Identity
     Name="Microsoft.WindowsTerminalPreview"
@@ -34,6 +35,7 @@
         <virtualization:ExcludedKey>HKEY_CURRENT_USER\Console\%%Startup</virtualization:ExcludedKey>
       </virtualization:ExcludedKeys>
     </virtualization:RegistryWriteVirtualization>
+    <uap17:UpdateWhileInUse>defer</uap17:UpdateWhileInUse>
   </Properties>
 
   <Dependencies>
diff --git a/src/cascadia/CascadiaPackage/Package.appxmanifest b/src/cascadia/CascadiaPackage/Package.appxmanifest
index c123778d1e9..f04863da27c 100644
--- a/src/cascadia/CascadiaPackage/Package.appxmanifest
+++ b/src/cascadia/CascadiaPackage/Package.appxmanifest
@@ -9,13 +9,14 @@
   xmlns:uap4="http://schemas.microsoft.com/appx/manifest/uap/windows10/4"
   xmlns:uap5="http://schemas.microsoft.com/appx/manifest/uap/windows10/5"
   xmlns:uap7="http://schemas.microsoft.com/appx/manifest/uap/windows10/7"
+  xmlns:uap17="http://schemas.microsoft.com/appx/manifest/uap/windows10/17"
   xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10"
   xmlns:desktop4="http://schemas.microsoft.com/appx/manifest/desktop/windows10/4"
   xmlns:desktop5="http://schemas.microsoft.com/appx/manifest/desktop/windows10/5"
   xmlns:desktop6="http://schemas.microsoft.com/appx/manifest/desktop/windows10/6"
   xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
   xmlns:virtualization="http://schemas.microsoft.com/appx/manifest/virtualization/windows10"
-  IgnorableNamespaces="uap mp rescap uap3 desktop6 virtualization">
+  IgnorableNamespaces="uap mp rescap uap3 uap17 desktop6 virtualization">
 
   <Identity
     Name="Microsoft.WindowsTerminal"
@@ -34,6 +35,7 @@
         <virtualization:ExcludedKey>HKEY_CURRENT_USER\Console\%%Startup</virtualization:ExcludedKey>
       </virtualization:ExcludedKeys>
     </virtualization:RegistryWriteVirtualization>
+    <uap17:UpdateWhileInUse>defer</uap17:UpdateWhileInUse>
   </Properties>
 
   <Dependencies>


Test patch: