Repository navigation
[Bug - Edge Addons] All extensions are blocked on *.cloud.microsoft starting in Edge ≥150 with no override #644
Description
Activity
We're hitting this too.
Context: we build an enterprise security extension that IT admins force-install
on managed devices. One of its jobs is showing acceptable-use and training
prompts when employees open M365 Copilot. It's the tooling that lets security
teams approve Copilot rollouts in the first place.What we're seeing:
- Edge 150 broke this silently for our whole fleet. Worked fine on 149.
- Still works on Chrome and every other Chromium browser.
- No release note, no deprecation window.
- No override: runtime_allowed_hosts does nothing, and force-installed
extensions are blocked the same as everything else.
Expected behavior:
- Honor runtime_allowed_hosts for policy-installed extensions on these origins.
Hi myname (@AdeledePremonville)
Thank you for reporting this issue. To help us investigate further and determine whether this is a regression, policy-related behavior, or expected functionality, could you please provide the following details?
1. Sample Extension
- A minimal test extension or a publicly available extension that demonstrates the issue (for example, Bitwarden, as mentioned in the report).
- The extension ID and store link.
2. Specific Affected URLs
- The exact *.cloud.microsoft URLs where the issue occurs.
- For example, specific Microsoft 365 Copilot page URLs rather than a generic domain reference.
3. Evidence of the Regression
- A video recording comparing the behavior in Edge 149 and Edge 150.
- Screenshots showing the extension functioning in Edge 149 and no longer functioning in Edge 150.
4. Extension Diagnostics
Any relevant error messages or logs from:
- DevTools Console
- Service Worker Console (edge://extensions)
- Extension error logs
5. Policy Validation Information
Screenshots of:
- edge://policy
- edge://version
Confirmation that the policies are being applied successfully, including the exact ExtensionSettings configuration being used.
6. Manifest Details
- Manifest version (MV2 or MV3).
- The host permissions requested by the extension.
7. Clean Profile Reproduction
- Confirmation of whether the issue can be reproduced on a fresh Edge 150 profile without any enterprise policies applied.
These details will help us reproduce the issue accurately and assist the engineering team with further investigation. Thank you.
Thanks for looking into this. Here are steps to reproduce with Bitwarden.
Summary: The Bitwarden extension stops functioning on "https://m365.cloud.microsoft/chat" after updating from Edge 149 to 150. Rolling back to 149.0.4022.98 resolves it, which points to a regression introduced in 150.
Environment:
- Broken on: Edge [150.0.4078.48] (Stable, Latest)
- Working on: Edge 149.0.4022.98 (Stable)
-
- Extension ID: jbkfoedolllekgbhcbcoahefnbanhhlh
- Store listing: https://microsoftedge.microsoft.com/addons/detail/jbkfoedolllekgbhcbcoahefnbanhhlh
Steps to reproduce:
- On Edge 150, install Bitwarden (or any extension)
- Navigate to https://m365.cloud.microsoft/chat
- Click the extension icon while on that page.
Observed behavior: The extension page will not work. There will be a disclaimer in the extension dropdown saying explicitly, "Extensions are not allowed on m365.cloud.microsoft". The same extension and same URL work normally on 149.
Expected behavior: The extension should function on this domain, as it does on 149.Screenshots attached:
Allowed on Edge 149
Blocked on Edge 150
No enterprise policies
Reacted by myname, captixn and adrian-pattzIn case it helps, I also observe the very same issue. It's the same for any extension for Copilot domain on Edge.
Reacted by Bennett Hensey, Rahul-Bauri, myname and adrian-pattzHi Bennett Hensey (@bhensey), Thank you for taking the time to provide the detailed reproduction steps and screenshots demonstrating the issue. I have shared the information with the relevant internal team for further investigation. I will update you as soon as I receive any additional information regarding this issue.
Reacted by myname and captixnHi Bennett Hensey (@bhensey) captixn, I received the following response from our team regarding this issue:
Currently, extensions are not designed to work with Copilot. At this time, the list of sites where Microsoft extensions are blocked includes Copilot, Edge:// pages, and EAS*. However, your feedback is valuable and helps us better understand the potential need for extension support in Copilot. If you could share more specific use cases, it would help inform future discussions and product decisions. Thanks for your understanding.
Rahul-Bauri For us and our clients, this is a blocker. Our company, Mendo, develops an extension that helps user use Copilot by inserting a script that displays a widget, guiding users towards prompting in a specific way and giving real-time feedback. It benefits Microsoft because it drives the adoption of Copilot up, a key strategic business priority. We are an ECIF partner and well-known at Microsoft France. We will escale with the Direction of AI Business Solution Europe and through our key accounts.
One of our extension: https://chromewebstore.google.com/detail/mendo-copilot/jmgalbpmjmakkcpeofjdldohaenibcpp
Meanwhile, please also escalate this to this specific team. At the very least, there should be an admin configurable to control this. I understand the restrictions is new, undocumented, and recent.
Bennett Hensey (@bhensey) Could you ask your clients [or your head of sales/care/account manager] to escalate through your enterprise clients ? Ideally they would contact their Microsoft partner. I have asked the same of my teams so Microsoft can get the word that this behavior doesn't serve their clients.
Reacted by Bennett HenseyUpdate: We got confirmation that this is acknowledged as a bug and will be fixed in the version 152. This new version will be released on 27th August 2026.
Reacted by Rahul-Bauri, Bennett Hensey, Grant, 0xADADA and Alessandro MaurizioReacted by Gaurav MahajanHi captixn
Greatly appreciate the update here. Would you happen to have any details or links to documentation/ internal ticket/ contacts confirming this is being worked on? Trying to escalate this within MSFT for one of my customers too.
Thank you
Agreed, Rahul-Bauri can you please confirm that this bug will be resolved in version 152? It would be great to have this notice from an authoritative Microsoft source.
And on timeline, is it possible to move this bug fix into the version 151 beta? I'm assuming it's a small configuration change, and the fix is high-urgency given it's an undocumented regression affecting enterprise partners.
Reacted by Gaurav Mahajan, Guy Gofman, Yuval Meshorer and briankunerHi from CrowdStrike here, this issue also impacts CrowdStrike Falcon Browser Extension. Thus far we've discovered the block impacts the following domains:
*.cloud.microsoftedgeservices.bing.comcopilot.microsoft.comexplore.microsoft.comwww.microsoft365.com
Hi Rahul-Bauri, could you share any official statement this will be fixed in 152?
clarolab-pablo linked from above #644 (comment)
Update: We got confirmation that this is acknowledged as a bug and will be fixed in the version 152. This new version will be released on 27th August 2026.
Reacted by clarolab-pabloI tested with Edge 151 Beta
151.0.4129.35fixed the issue onm365.cloud.microsoftandforms.cloud.microsoftbut the others in my list remain blocked:- edgeservices.bing.com
- copilot.microsoft.com
- explore.microsoft.com
- www.microsoft365.com
Reacted by Grant, captixn, idan-lx, Alex and Bennett HenseyEdge 153 Beta arrived this week macOS/windows, some initial findings:
151
m365.cloud.microsoftfixed in151forms.cloud.microsoftfixed in151
153
www.microsoft365.comredirects tohttps://m365.cloud.microsoft/(fixed)copilot.microsoft.comfixed in153macOS/Windowsedgeservices.bing.comfixed in153macOSexplore.microsoft.comfixed in153macOSedgeservices.bing.comextension blacklisted in153.0.4234.6 ARM64Windowsexplore.microsoft.comextension blacklisted in153.0.4234.6 ARM64Windows
Reacted by Bennett HenseyI am still seeing "Extensions are not allowed on copilot.microsoft.com"
Microsoft Edge 154.0.4258.37 (Official build) (x86_64) Revision f6ddc7bb8d2ad05a6979ebc09b83893c2d128a62 Chromium version 154.0.8037.58 Operating system LinuxReacted by Bennett HenseyRahul-Bauri Do you know when the
copilot.microsoft.comfix will be released? I verified the fix in 153 beta, so it must have been intentionally removed from the past 2 GA releases.0xADADA (@0xadada) thank you for following up
Edge Beta 155 arrived this week, it appears
*.cloud.microsofthas been resolved.edgeservices.bing.comandexplore.microsoft.comare still blacklisting extensions. I assume because they're treated as a default homepage or unscriptable gallery page, but without transparency on why, its just unclear.
Extension ability to run on microsoft domains in Edge
Domain macOS Windows/ARM64 Browser version/Notes m365.cloud.microsoft✅ ✅ Edge 151 forms.cloud.microsoft✅ ✅ Edge 151 copilot.com✅ ✅ Edge 153 copilot.com✅ ✅ Edge Beta 155 edgeservices.bing.com✅ 🚫 Edge 153 edgeservices.bing.com✅ 🚫 Edge Beta 155 explore.microsoft.com✅ 🚫 Edge 153 explore.microsoft.com✅ 🚫 Edge Beta 155 Reacted by clarolab-pablo and Bennett Hensey
Describe the bug
Starting with Microsoft Edge 150, the browser applies a hardcoded extension blocklist to *.cloud.microsoft (the M365 Copilot / Microsoft 365 app surfaces). On these pages, extensions no longer run. This is a regression: on Edge 149 and earlier, extensions worked normally on these same pages.
The block affects ALL extensions — not just a specific category, and not only enterprise/managed scenarios. It cannot be overridden by ExtensionSettings → runtime_allowed_hosts, by ExtensionInstallForcelist (force install), or by any documented policy. 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.
Verified breakage:
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Extensions run on *.cloud.microsoft pages exactly as they do on every other domain, and as they did in Edge 149. At minimum, there should be an override (or the existing force-install / runtime_allowed_hosts allowlist should be honored) so users and admins can re-enable extensions on these surfaces.
Screenshots
N/A (can provide edge://policy and edge://version screenshots on request).
Desktop (please complete the following information):
Additional context
This is a behavior change introduced between Edge 149 and 150. The block appears to be independent of any configurable policy: ExtensionInstallForcelist and ExtensionSettings runtime_allowed_hosts have no effect on *.cloud.microsoft. Please either restore pre-150 behavior, provide a policy/override so extensions can run on these pages, or, if this is by design, document the exemption in the ExtensionSettings and ExtensionInstallForcelist policy references so users and admins understand it cannot be configured away.
Policy reference pages affected: