Microsoft has added a Windows 11 policy called “Remove Microsoft Copilot app” for managed PCs, giving administrators a supported way to uninstall the consumer Copilot app when Microsoft 365 Copilot is also present and specific usage conditions are met. The change matters less because it removes one app than because it admits a larger truth: Copilot is now a fleet-management problem, not just a taskbar icon. Microsoft is no longer merely asking users to try AI in Windows; it is forcing IT departments to define where Copilot belongs, which Copilot they mean, and how much of it should survive the next update cycle.
For the last two years, Copilot has been treated as both a product and a destiny. It appeared in Windows, Edge, Microsoft 365, keyboards, Start menu surfaces, and inbox app experiences with the inevitability of a feature Microsoft had already decided would become infrastructure. The new removal policy is therefore not a retreat from AI. It is a concession that unmanaged enthusiasm does not scale across managed desktops.
The new Group Policy is named “Remove Microsoft Copilot app” and appears under User Configuration → Administrative Templates → Windows Components → Windows AI. Its corresponding policy name is RemoveMicrosoftCopilotApp, and Microsoft also exposes it through the WindowsAI Policy CSP for modern management tools.
That placement is revealing. Copilot is no longer being handled as a stray consumer app or a convenience feature bolted to the shell. It sits in the same administrative neighborhood as other Windows AI controls, which means Microsoft increasingly sees AI experiences as part of the operating system’s policy surface.
The policy’s scope is also deliberately narrow. According to Microsoft’s documented behavior, it applies only when Microsoft 365 Copilot and the consumer Microsoft Copilot app are both installed, when the consumer Copilot app was not installed by the user, and when that app has not been launched in the previous 28 days. If those conditions are met and the policy is enabled, Windows can remove the consumer Copilot app.
That is not the same as a universal “delete Copilot from Windows” switch. It is closer to a cleanup rule for duplicate, unused, Microsoft-seeded Copilot entry points. Microsoft’s argument is implicit: if the enterprise already has the Microsoft 365 Copilot experience and the user has ignored the consumer app for four weeks, removing the redundant app is not disruptive.
For administrators, that is useful. For skeptics, it is also frustrating. The policy does not say, “We heard you; here is one master kill switch.” It says, “Here is one sanctioned path through a maze we created.”
Microsoft is trying to avoid the appearance, and the operational reality, of ripping away an app that a user has chosen to use. If the consumer Copilot app was manually installed by the user, the policy does not target it. If the app has been opened recently, the policy does not target it. If only one Copilot flavor is installed, the intended cleanup scenario may not exist.
That makes the policy less like classic software restriction and more like telemetry-aware housekeeping. Microsoft is distinguishing between user intent, administrative intent, and vendor-driven installation. In practical terms, it is saying that an app Microsoft placed on the system can be removed by policy if the user has not expressed interest in it.
This is a defensible design, but it also reveals how awkward the Copilot rollout has become. A clean enterprise product strategy would not require Windows to infer whether a duplicated AI app is wanted based on launch history. It would give organizations an explicit deployment model before the app lands, not a conditional removal mechanism after the fact.
The 28-day rule also creates a subtle administrative wrinkle. Help desks will need to understand why the same policy removes Copilot for one user but not another. A user who clicked the app out of curiosity three weeks ago may keep it, while a neighboring user who never opened it may lose it. That is not necessarily a bug, but it is the kind of condition that turns a simple control into a support note.
The older “Turn off Windows Copilot” policy and its registry equivalent under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsCopilot with a TurnOffWindowsCopilot DWORD could disable the Windows Copilot experience and hide visible entry points in supported builds. Intune administrators could push the same idea through the Settings Catalog. These controls were useful, especially when Copilot was primarily understood as a shell feature.
But the Copilot product changed underneath those controls. The Windows Copilot pane gave way to app-based experiences. Microsoft 365 Copilot gained its own presence. Edge, Office, Notepad, Paint, Photos, and other surfaces developed their own AI affordances. The result was a management distinction that ordinary users rarely care about but IT departments cannot ignore: disabling one Copilot surface does not necessarily disable all Copilot-branded functionality.
That is why AppLocker packaged app rules became part of the administrator playbook. Blocking packages such as Microsoft.Copilot can prevent execution or installation paths more forcefully than hiding a button. PowerShell removal commands can uninstall an Appx package in the current context. But those methods are brittle in the way Windows customization often is: they may work today, then be undone by a feature update, a Store update, or a provisioning change.
The community reports about Copilot returning after Windows updates fit a long-standing Windows pattern. Manual removals are often treated as local state, while Microsoft’s servicing model continues to enforce the desired baseline for a given edition, region, account type, or update channel. Unless a removal is backed by a supported policy, administrators are fighting the installer rather than instructing it.
There is the consumer Copilot app, which behaves like a general-purpose AI assistant. There is Microsoft 365 Copilot, tied to organizational identity, enterprise data boundaries, and licensing. There are Copilot-branded controls inside Microsoft 365 apps. There are Windows-level AI features that may or may not carry the Copilot name. There are hardware keys on new PCs that users reasonably assume should open something called Copilot, unless an admin or user remaps them.
This is branding strategy colliding with systems administration. Microsoft wants Copilot to be the common name for AI assistance across its stack. IT wants each component to have a distinct package name, policy path, data boundary, update cadence, and audit story. Those goals are not mutually exclusive, but they are in tension.
RemoveMicrosoftCopilotApp is aimed at one precise slice of that tension: the consumer Copilot app on devices where Microsoft 365 Copilot is also installed. That distinction matters because organizations generally prefer enterprise-governed AI experiences over consumer ones on corporate hardware. A company may be comfortable with Microsoft 365 Copilot under its tenant controls while still wanting to remove the consumer app from managed desktops.
For users, the distinction can look absurd. They see two Copilots, or a Copilot key that opens the wrong Copilot, or a Copilot feature in an app after the Copilot app has been removed. For administrators, the distinction is the difference between a compliant deployment and a data-governance headache.
Microsoft’s challenge is that it has trained the market to see Copilot as a single umbrella while asking admins to manage it as a collection of separate objects. The new policy helps, but it also confirms that the umbrella is getting heavy.
The policy’s supported-management angle is important. In large environments, the difference between “a PowerShell command that works in testing” and “a Microsoft-documented policy surface” is enormous. The former is a workaround. The latter can be assigned, audited, explained, and defended during change control.
Still, the narrowness matters. This is not a privacy master switch. It does not disable every AI feature in Windows. It does not remove Copilot from Edge, eliminate Copilot functionality in Microsoft 365 apps, or guarantee that future Windows features branded with Copilot will obey the same setting. It removes a particular app under particular conditions.
That is why the best administrative strategy remains layered. Organizations that want a low-Copilot or no-consumer-Copilot environment should combine the new removal policy with existing controls: Intune configuration, legacy Copilot disablement where still applicable, AppLocker or App Control rules, Microsoft 365 admin settings, and clear user communication.
The risk is not that RemoveMicrosoftCopilotApp fails to do what it says. The risk is that its name sounds broader than its actual scope. Admins who treat it as the one Copilot control to rule them all will likely be disappointed.
Some users can uninstall the Copilot app through Settings if the app appears as a normal installed package. Others can remove it with PowerShell commands such as Get-AppxPackage followed by Remove-AppxPackage. Some can disable visible Copilot entry points through registry policy values, depending on edition and build. Windows 11 Pro users have more Group Policy access than Windows 11 Home users, though registry-backed policies can sometimes achieve similar effects.
But the problem for home users is persistence. Removing an inbox or provisioned app does not always mean it stays removed forever. Windows feature updates, Store app updates, Microsoft account experiences, and region-specific rollout changes can all reintroduce components. The result is the same maintenance burden that power users have faced for years with consumer features they regard as bloat.
This is where Microsoft’s enterprise-first cleanup path may irritate enthusiasts. The company has created a supported mechanism for admins to remove the consumer Copilot app when Microsoft 365 Copilot is present, but individual users who simply do not want Copilot at all are still left assembling their own toolkit. The power user gets more control than the average user, but less certainty than the enterprise admin.
That asymmetry is not new. Windows has long given organizations deeper policy hooks than consumers. But AI makes the gap feel sharper because Copilot is not just another suggested app. It is a cloud-connected assistant with branding that appears across productivity, search, chat, and operating-system surfaces.
What has changed is the administrative maturity of the rollout. Early Copilot deployment often felt like marketing outrunning management. Buttons appeared before policies were fully understood. App experiences shifted faster than documentation. The same name attached itself to separate technical products. Enthusiasts complained about bloat; administrators complained about ambiguity.
The new removal policy is part of Microsoft’s adjustment. It acknowledges that AI assistants need lifecycle controls just like browsers, sync clients, consumer apps, and security agents. They need installation logic, removal logic, disablement logic, and exceptions for user intent. They need to respect the difference between a personally owned laptop and a regulated corporate endpoint.
The catch is that Microsoft is trying to add those controls while still pushing Copilot forward aggressively. That creates a two-track experience. On one track, Microsoft tells customers that Copilot is central to the future of Windows. On the other, it quietly adds policies to remove or suppress Copilot surfaces when they become operationally messy.
That is not hypocrisy so much as platform politics. Microsoft wants Copilot everywhere that helps adoption, but not so everywhere that it triggers enterprise resistance. The new policy is a pressure valve.
This is a targeted cleanup control for environments where Microsoft’s consumer Copilot app and Microsoft 365 Copilot coexist. It is not a universal AI-disablement framework. It does not replace tenant-level Microsoft 365 Copilot governance, app control, Edge policies, or user education. It is one more instrument in a growing Windows AI policy set.
Administrators should also treat build availability carefully. Reporting around the feature points to recent Windows 11 preview builds, and Microsoft documentation now describes the policy in the WindowsAI Policy CSP. As always with Windows policy work, the difference between Insider builds, general availability builds, ADMX availability, and MDM support can matter in the field.
For cautious IT teams, the right move is not to rip out existing Copilot controls immediately. It is to test RemoveMicrosoftCopilotApp in a pilot ring, confirm which devices meet the removal conditions, document what remains after the policy applies, and decide whether additional controls are needed for Edge, Microsoft 365 apps, Store packages, or Windows AI features.
The policy should also be understood as user-scoped as well as device-aware. In shared-device or multi-user scenarios, launch history and installation origin may vary by user. That makes validation more important than assumption.
For the last two years, Copilot has been treated as both a product and a destiny. It appeared in Windows, Edge, Microsoft 365, keyboards, Start menu surfaces, and inbox app experiences with the inevitability of a feature Microsoft had already decided would become infrastructure. The new removal policy is therefore not a retreat from AI. It is a concession that unmanaged enthusiasm does not scale across managed desktops.
Microsoft Turns Copilot From Branding Into Policy
The new Group Policy is named “Remove Microsoft Copilot app” and appears under User Configuration → Administrative Templates → Windows Components → Windows AI. Its corresponding policy name is RemoveMicrosoftCopilotApp, and Microsoft also exposes it through the WindowsAI Policy CSP for modern management tools.That placement is revealing. Copilot is no longer being handled as a stray consumer app or a convenience feature bolted to the shell. It sits in the same administrative neighborhood as other Windows AI controls, which means Microsoft increasingly sees AI experiences as part of the operating system’s policy surface.
The policy’s scope is also deliberately narrow. According to Microsoft’s documented behavior, it applies only when Microsoft 365 Copilot and the consumer Microsoft Copilot app are both installed, when the consumer Copilot app was not installed by the user, and when that app has not been launched in the previous 28 days. If those conditions are met and the policy is enabled, Windows can remove the consumer Copilot app.
That is not the same as a universal “delete Copilot from Windows” switch. It is closer to a cleanup rule for duplicate, unused, Microsoft-seeded Copilot entry points. Microsoft’s argument is implicit: if the enterprise already has the Microsoft 365 Copilot experience and the user has ignored the consumer app for four weeks, removing the redundant app is not disruptive.
For administrators, that is useful. For skeptics, it is also frustrating. The policy does not say, “We heard you; here is one master kill switch.” It says, “Here is one sanctioned path through a maze we created.”
The 28-Day Clock Says More Than the Toggle
The most interesting part of RemoveMicrosoftCopilotApp is not the word remove. It is the 28-day usage condition.Microsoft is trying to avoid the appearance, and the operational reality, of ripping away an app that a user has chosen to use. If the consumer Copilot app was manually installed by the user, the policy does not target it. If the app has been opened recently, the policy does not target it. If only one Copilot flavor is installed, the intended cleanup scenario may not exist.
That makes the policy less like classic software restriction and more like telemetry-aware housekeeping. Microsoft is distinguishing between user intent, administrative intent, and vendor-driven installation. In practical terms, it is saying that an app Microsoft placed on the system can be removed by policy if the user has not expressed interest in it.
This is a defensible design, but it also reveals how awkward the Copilot rollout has become. A clean enterprise product strategy would not require Windows to infer whether a duplicated AI app is wanted based on launch history. It would give organizations an explicit deployment model before the app lands, not a conditional removal mechanism after the fact.
The 28-day rule also creates a subtle administrative wrinkle. Help desks will need to understand why the same policy removes Copilot for one user but not another. A user who clicked the app out of curiosity three weeks ago may keep it, while a neighboring user who never opened it may lose it. That is not necessarily a bug, but it is the kind of condition that turns a simple control into a support note.
The Old Copilot Controls Were Always a Patchwork
Before this new policy, administrators and power users relied on a familiar mix of Group Policy, registry edits, Intune settings, AppLocker rules, and PowerShell commands. Each worked on a slice of the problem, but none fully answered the question most users were really asking: “How do I make Copilot stay gone?”The older “Turn off Windows Copilot” policy and its registry equivalent under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsCopilot with a TurnOffWindowsCopilot DWORD could disable the Windows Copilot experience and hide visible entry points in supported builds. Intune administrators could push the same idea through the Settings Catalog. These controls were useful, especially when Copilot was primarily understood as a shell feature.
But the Copilot product changed underneath those controls. The Windows Copilot pane gave way to app-based experiences. Microsoft 365 Copilot gained its own presence. Edge, Office, Notepad, Paint, Photos, and other surfaces developed their own AI affordances. The result was a management distinction that ordinary users rarely care about but IT departments cannot ignore: disabling one Copilot surface does not necessarily disable all Copilot-branded functionality.
That is why AppLocker packaged app rules became part of the administrator playbook. Blocking packages such as Microsoft.Copilot can prevent execution or installation paths more forcefully than hiding a button. PowerShell removal commands can uninstall an Appx package in the current context. But those methods are brittle in the way Windows customization often is: they may work today, then be undone by a feature update, a Store update, or a provisioning change.
The community reports about Copilot returning after Windows updates fit a long-standing Windows pattern. Manual removals are often treated as local state, while Microsoft’s servicing model continues to enforce the desired baseline for a given edition, region, account type, or update channel. Unless a removal is backed by a supported policy, administrators are fighting the installer rather than instructing it.
Copilot Has Become a Naming Problem With Administrative Consequences
One reason the new policy matters is that “Copilot” no longer means one thing.There is the consumer Copilot app, which behaves like a general-purpose AI assistant. There is Microsoft 365 Copilot, tied to organizational identity, enterprise data boundaries, and licensing. There are Copilot-branded controls inside Microsoft 365 apps. There are Windows-level AI features that may or may not carry the Copilot name. There are hardware keys on new PCs that users reasonably assume should open something called Copilot, unless an admin or user remaps them.
This is branding strategy colliding with systems administration. Microsoft wants Copilot to be the common name for AI assistance across its stack. IT wants each component to have a distinct package name, policy path, data boundary, update cadence, and audit story. Those goals are not mutually exclusive, but they are in tension.
RemoveMicrosoftCopilotApp is aimed at one precise slice of that tension: the consumer Copilot app on devices where Microsoft 365 Copilot is also installed. That distinction matters because organizations generally prefer enterprise-governed AI experiences over consumer ones on corporate hardware. A company may be comfortable with Microsoft 365 Copilot under its tenant controls while still wanting to remove the consumer app from managed desktops.
For users, the distinction can look absurd. They see two Copilots, or a Copilot key that opens the wrong Copilot, or a Copilot feature in an app after the Copilot app has been removed. For administrators, the distinction is the difference between a compliant deployment and a data-governance headache.
Microsoft’s challenge is that it has trained the market to see Copilot as a single umbrella while asking admins to manage it as a collection of separate objects. The new policy helps, but it also confirms that the umbrella is getting heavy.
The Enterprise Win Is Real, but It Is Narrow
For managed organizations, the new policy is good news. It gives IT a supported mechanism to remove a redundant consumer-facing app without relying on one-off scripts or unsupported cleanup jobs. It also aligns with a more rational enterprise posture: if Microsoft 365 Copilot is the approved assistant, the consumer app should not be cluttering corporate devices by default.The policy’s supported-management angle is important. In large environments, the difference between “a PowerShell command that works in testing” and “a Microsoft-documented policy surface” is enormous. The former is a workaround. The latter can be assigned, audited, explained, and defended during change control.
Still, the narrowness matters. This is not a privacy master switch. It does not disable every AI feature in Windows. It does not remove Copilot from Edge, eliminate Copilot functionality in Microsoft 365 apps, or guarantee that future Windows features branded with Copilot will obey the same setting. It removes a particular app under particular conditions.
That is why the best administrative strategy remains layered. Organizations that want a low-Copilot or no-consumer-Copilot environment should combine the new removal policy with existing controls: Intune configuration, legacy Copilot disablement where still applicable, AppLocker or App Control rules, Microsoft 365 admin settings, and clear user communication.
The risk is not that RemoveMicrosoftCopilotApp fails to do what it says. The risk is that its name sounds broader than its actual scope. Admins who treat it as the one Copilot control to rule them all will likely be disappointed.
Home Users Are Still Stuck in the Workaround Economy
The new policy is most meaningful for managed Windows environments. Home users, meanwhile, remain in the familiar position of searching for registry edits, PowerShell commands, Store uninstall options, and third-party guides.Some users can uninstall the Copilot app through Settings if the app appears as a normal installed package. Others can remove it with PowerShell commands such as Get-AppxPackage followed by Remove-AppxPackage. Some can disable visible Copilot entry points through registry policy values, depending on edition and build. Windows 11 Pro users have more Group Policy access than Windows 11 Home users, though registry-backed policies can sometimes achieve similar effects.
But the problem for home users is persistence. Removing an inbox or provisioned app does not always mean it stays removed forever. Windows feature updates, Store app updates, Microsoft account experiences, and region-specific rollout changes can all reintroduce components. The result is the same maintenance burden that power users have faced for years with consumer features they regard as bloat.
This is where Microsoft’s enterprise-first cleanup path may irritate enthusiasts. The company has created a supported mechanism for admins to remove the consumer Copilot app when Microsoft 365 Copilot is present, but individual users who simply do not want Copilot at all are still left assembling their own toolkit. The power user gets more control than the average user, but less certainty than the enterprise admin.
That asymmetry is not new. Windows has long given organizations deeper policy hooks than consumers. But AI makes the gap feel sharper because Copilot is not just another suggested app. It is a cloud-connected assistant with branding that appears across productivity, search, chat, and operating-system surfaces.
Microsoft Is Learning That AI Needs an Off-Ramp
The broader story is not that Microsoft has suddenly soured on Copilot. It has not. The company continues to build AI into Windows and Microsoft 365 because it sees AI as the next platform layer, a way to defend Office, modernize Windows, and keep users inside Microsoft’s cloud.What has changed is the administrative maturity of the rollout. Early Copilot deployment often felt like marketing outrunning management. Buttons appeared before policies were fully understood. App experiences shifted faster than documentation. The same name attached itself to separate technical products. Enthusiasts complained about bloat; administrators complained about ambiguity.
The new removal policy is part of Microsoft’s adjustment. It acknowledges that AI assistants need lifecycle controls just like browsers, sync clients, consumer apps, and security agents. They need installation logic, removal logic, disablement logic, and exceptions for user intent. They need to respect the difference between a personally owned laptop and a regulated corporate endpoint.
The catch is that Microsoft is trying to add those controls while still pushing Copilot forward aggressively. That creates a two-track experience. On one track, Microsoft tells customers that Copilot is central to the future of Windows. On the other, it quietly adds policies to remove or suppress Copilot surfaces when they become operationally messy.
That is not hypocrisy so much as platform politics. Microsoft wants Copilot everywhere that helps adoption, but not so everywhere that it triggers enterprise resistance. The new policy is a pressure valve.
The Practical Reading for Windows Admins Is Smaller Than the Headline
The headline version is simple: Windows 11 is getting a policy to remove the Copilot app. The operational version is more constrained and more useful.This is a targeted cleanup control for environments where Microsoft’s consumer Copilot app and Microsoft 365 Copilot coexist. It is not a universal AI-disablement framework. It does not replace tenant-level Microsoft 365 Copilot governance, app control, Edge policies, or user education. It is one more instrument in a growing Windows AI policy set.
Administrators should also treat build availability carefully. Reporting around the feature points to recent Windows 11 preview builds, and Microsoft documentation now describes the policy in the WindowsAI Policy CSP. As always with Windows policy work, the difference between Insider builds, general availability builds, ADMX availability, and MDM support can matter in the field.
For cautious IT teams, the right move is not to rip out existing Copilot controls immediately. It is to test RemoveMicrosoftCopilotApp in a pilot ring, confirm which devices meet the removal conditions, document what remains after the policy applies, and decide whether additional controls are needed for Edge, Microsoft 365 apps, Store packages, or Windows AI features.
The policy should also be understood as user-scoped as well as device-aware. In shared-device or multi-user scenarios, launch history and installation origin may vary by user. That makes validation more important than assumption.
Redmond’s Copilot Cleanup Leaves a Manageable, Uneven Map
The useful facts for WindowsForum readers are concrete, but the implication is broader: Microsoft has begun turning Copilot backlash into policy plumbing rather than press statements.- The new RemoveMicrosoftCopilotApp policy is designed to uninstall the consumer Microsoft Copilot app only when Microsoft 365 Copilot is also installed and the consumer app appears unused and Microsoft-installed.
- The older TurnOffWindowsCopilot policy and registry value remain relevant in some scenarios, but Microsoft’s newer app-based Copilot direction means they should not be treated as complete removal tools.
- AppLocker or App Control rules remain important when organizations want to prevent Copilot packages from running or returning through normal app channels.
- PowerShell removal can work for individual machines or remediation scripts, but community experience suggests that unsupported removals may not survive every Windows update or provisioning path.
- Home users still have fewer clean options than managed organizations, especially on Windows 11 Home, where Group Policy tooling is limited and update-driven reinstalls can undermine manual cleanup.
- The biggest administrative task is now classification: deciding which Copilot experiences are approved, which are redundant, and which must be blocked for governance or usability reasons.
References
- Primary source: Let's Data Science
Published: 2026-05-23T19:50:08.156034
Windows 11 adds policy to remove Copilot app
Windows Latest reports that a recent Windows 11 preview build adds a Group Policy named "Remove Microsoft Copilot app," located at User Configuration > Administrative Templates > Windows Components > Windows AI, which can remove the consumer Copilot app and bundled Microsoft 365 Copilot on...
letsdatascience.com
- Related coverage: windowscentral.com
Don't like Windows 11's Copilot key? Microsoft confirms it will let you remap it later this year
Windows 11's special Copilot Key has not been the popular hit that Microsoft was hoping it would be, and has now confirmed plans to let users remap the button back to its old functionality.
www.windowscentral.com
- Official source: learn.microsoft.com
Updated Windows and Microsoft 365 Copilot Chat experience
Learn about changes to the Copilot in Windows experience for commercial environments and how to configure it for your organization.learn.microsoft.com - Related coverage: tomshardware.com
Admins finally get the power to uninstall Microsoft Copilot on Windows 11 Pro, Enterprise, and EDU versions — devices must meet specific conditions to allow the removal of the AI app
One less bloatware on Windows 11.www.tomshardware.com
- Related coverage: tweakers.net
Microsoft laat admins Copilot-app verwijderen van beheerde Windows 11-apparaten
Microsoft test de mogelijkheid voor admins om AI-assistent Copilot van beheerde Windows-apparaten te verwijderen via een Group Policy, mits gebruikers voldoen aan diverse voorwaarden. Tot dusver is het alleen mogelijk om Microsoft 365 Copilot te verwijderen.tweakers.net
- Related coverage: technobezz.com
Microsoft Lets IT Admins Uninstall Copilot App from Managed Windows 11 Devices
Microsoft now allows IT admins to remove the free Copilot app from managed Windows 11 devices under specific conditions.
www.technobezz.com
- Related coverage: windowsreport.com
- Related coverage: tomsguide.com
- Related coverage: windowsforum.com
Remove Microsoft Copilot on Windows 11 with Group Policy (Insider Preview)
Microsoft has quietly given administrators a supported—but deliberately narrow—way to remove the consumer Microsoft Copilot app from managed Windows 11 devices through a new Group Policy surfaced in the January 2026 Insider Preview. Background / Overview Windows 11’s Copilot ecosystem now...
windowsforum.com
- Related coverage: howtogeek.com
How to Disable Windows Copilot
Window Copilot is great, but it's not for everyone.
www.howtogeek.com
- Related coverage: anavem.com
- Related coverage: techradar.com
- Related coverage: vendorcompliance.surf.nl
- Related coverage: libraryfreedom.org