Forum Discussion
Edge >=150 blocks ALL extensions on *.cloud.microsoft (regression from 149) - no policy override
Starting with Edge 150, a hardcoded extension blocklist applies to *.cloud.microsoft (M365 Copilot and Microsoft 365 app surfaces). Extensions no longer run on these pages. This is a regression - on Edge 149 and earlier it worked fine on the same pages.
The block affects all extensions, not a specific category, and it is not overridable via ExtensionSettings (runtime_allowed_hosts), ExtensionInstallForcelist, or any other policy we have tested. It hits both regular user-installed extensions and admin-approved, force-installed extensions on managed devices - so admins have no way to re-enable trusted extensions on these surfaces either.
Confirmed breakage so far:
- Password managers - verified with Bitwarden (users end up copy/pasting credentials out of the manager on Copilot pages, a real security regression)
- Corporate training / user-adoption extensions
- Accessibility extensions relied on by employees
Ask to the Edge team: restore the pre-150 behavior, or ship an override so extensions can run on *.cloud.microsoft pages (for example, honor runtime_allowed_hosts / the force-install list on these surfaces). If this is by design, please document it clearly so users and admins stop chasing a config that cannot work.
Environment: Edge Stable >=150 (works on 149 and earlier), Windows, both unmanaged and MDM-managed (Intune/GPO). Reproducible on a clean profile with a single extension.
Are other users / admins / extension vendors seeing the same thing after updating to 150? Please add your affected extension below so Microsoft can gauge the blast radius.
1 Reply
Hi, this is a really good write-up, especially because you already tested the usual policy routes.
If `ExtensionSettings`, force-install, and a clean profile all behave the same way, I would treat this as either an intentional Edge service-side restriction or a regression in the Edge 150 policy handling for those Microsoft 365 surfaces. I do not think this is something an admin can cleanly fix with normal extension policy if Edge is blocking the host before the extension permission model is evaluated.
The most useful next step is to file it through Edge feedback or an enterprise support case with the Edge version, extension IDs, policy export, and a simple repro on `*.cloud.microsoft`. I would also test the same repro on Beta/Dev so you can tell Microsoft whether it is already fixed in a later channel. Short term, the only practical workaround may be documenting the affected extensions and keeping sensitive workflows out of those pages until Microsoft clarifies whether this is by design.
