We've been removing the standalone Copilot app from our fleet and it keeps coming back. We want to keep M365 Copilot (package name is Microsoft.OfficeHub), but remove the standalone app. Took us a while to track down why but it turns out MicrosoftEdgeUpdate.exe is managing it and it quietly puts it back during scheduled update runs.

For anyone who went down the same road we did: the Windows AI policy "Turn Off Copilot in Windows" doesn't stop this. It only affects the old Copilot-in-Windows experience baked into the OS, not the standalone app.

What seems to work is writing these two DWORDs under the EdgeUpdate policy key:

```
HKLM\SOFTWARE\Policies\Microsoft\EdgeUpdate
Install{C50565E9-CCCF-44B4-BA15-5AC5C6569197} = 0
Update{C50565E9-CCCF-44B4-BA15-5AC5C6569197} = 0
```

Microsoft documents the Install/Update GUID pattern for Edge and WebView2 but never listed Copilot. We pulled the GUID straight from the EdgeUpdate log when we caught it mid-install. OmahaPolicyManager picks the values up and registers install=0/update=0 for that GUID.

We’ve confirmed the policy is being read and Copilot hasn't come back, but we haven't actually watched it block a live install yet since there's no new version right now.

Curious if I’m missing something totally obvious (a different setting in the Settings Catalog maybe?), or if anyone else has successfully removed the standalone Copilot app a different way.

Also curious if anyone's seen different behavior on AD-joined vs Entra-only. I’m on an Entra-joined device though most of the fleet is domain joined (haven’t migrated yet) and the registry write worked fine even though Microsoft's docs kind of imply AD join is required for EdgeUpdate policies to apply.