GitHub Copilot App Enterprise Policy and Settings Guide

GitHub changed enterprise control of the GitHub Copilot app on July 27, 2026. The desktop app now has an access policy separate from Copilot CLI, and the app can enforce enterprise-managed settings for plugins, marketplaces, approval bypass, and default model selection. The change affects GitHub Copilot Business and Enterprise administrators, especially those who previously treated the CLI policy as the app’s gate. The practical consequence is immediate: GitHub says the new app policy is Enabled everywhere by default, so administrators should review access rather than assume an existing CLI restriction also blocks the app. Teams already using managed-settings.json can extend the same supported guardrails to the app without creating a second configuration.

Key takeaways

The GitHub Copilot app and Copilot CLI have independent access policies as of July 27, 2026.
GitHub set the new Copilot app policy to Enabled everywhere by default at launch.
Enterprise-managed settings apply across an enterprise with no organization-level override for supported keys.
The app supports managed plugin controls, marketplace restrictions, approval-bypass controls, and auto model selection; not every setting works on every client.
Server-managed, mobile device management (MDM), and file-based deployment use the same JSON schema but provide different coverage and precedence.
Access policy and behavioral guardrails solve different problems. Administrators should review both before approving the app.

What changed for GitHub Copilot app administrators

GitHub made two connected releases on July 27. First, the Copilot app received its own access policy. Previously, app access depended on the Copilot CLI policy. An enterprise can now enable the app while disabling the CLI, disable the app while retaining the CLI, or delegate the app decision to organization administrators.

Second, GitHub added the app to the clients that enforce enterprise-managed settings. A centrally distributed managed-settings.json can restrict supported behavior even after a user is allowed to sign in to the app.

These controls are complementary:

Control	What it decides	Available choices or examples
Copilot app access policy	Whether eligible users may use the app	Enabled everywhere, Disabled everywhere, Let organizations decide
Enterprise-managed settings	What supported Copilot clients may do	Plugin enablement, marketplace restrictions, approval-bypass control, default model selection
Repository and workflow controls	What changes may enter a codebase	Pull-request review, rulesets, required checks, code owners

The access policy is not a substitute for runtime guardrails, and managed settings do not replace repository protections. GitHub describes app work as occurring in isolated workspaces and landing through pull requests, but those characteristics do not make every generated change safe. Existing review and continuous integration controls still decide what can merge.

Review the default app policy first

GitHub says the new Copilot app policy launched as Enabled everywhere. That default matters most to enterprises that had deliberately disabled Copilot CLI and assumed the same setting prevented app use.

Enterprise or organization administrators can find the control under AI Controls → Copilot Clients → Copilot app. GitHub documents three choices:

Enabled everywhere allows developers covered by the policy to access the app.
Disabled everywhere blocks the app across the enterprise.
Let organizations decide delegates the choice to organization administrators.

According to GitHub’s current policy documentation, enterprise policy is evaluated first. For most Copilot policies, an enterprise can enable, disable, or delegate. Users assigned Copilot directly by the enterprise require extra attention: GitHub says the separate “Policies for enterprise-assigned users” setting determines how delegated policies behave for them.

Do not assume that every user with multiple Copilot relationships receives the same result. GitHub says the least restrictive policy usually wins between organizations in one enterprise, with exceptions, while the most restrictive policy almost always wins across different enterprises. Check the effective result for representative users instead of relying only on the configured value.

For a small team without enterprise policy needs, this July change has limited direct value: it is primarily an administration and governance control for organizations managing eligible users and devices at scale.

Understand what `managed-settings.json` controls

GitHub’s managed-settings reference lists each supported key and client. As of July 31, 2026, the main controls relevant to the Copilot app are:

Plugin and marketplace policy

enabledPlugins can require a named plugin to be enabled or disabled. extraKnownMarketplaces adds approved marketplace sources, while strictKnownMarketplaces restricts installation to sources explicitly listed by the enterprise. GitHub says an empty strictKnownMarketplaces array creates a complete marketplace lockdown.

These keys should be treated as a software-supply-chain policy. Identify who reviews a marketplace source, how a plugin version or Git reference is pinned, and how an approval is revoked. A marketplace allowlist confirms an approved source; it does not prove that every future change from that source is acceptable.

Approval-bypass policy

permissions.disableBypassPermissionsMode can prevent “allow all” behavior. In the Copilot app, GitHub says setting its value to "disable" blocks the Allow all option for tool permissions. The purpose is to stop users from globally bypassing prompts before an agent runs commands, reads files, or fetches URLs.

This reduces one category of accidental broad authorization, but it does not define which individual actions should be approved. Teams still need explicit rules for secrets, production systems, destructive commands, untrusted repositories, and external network access.

Default model selection

permissions.model set to "auto" makes automatic model selection the default for new conversations. GitHub’s reference says a user can still select a different model for an individual conversation. Therefore this setting is a default, not a model allowlist.

If model choice carries legal, data-location, contractual, or evaluation requirements, use the applicable GitHub model policies in addition to this client default. Do not interpret "auto" as a guarantee that one fixed model processes every request.

Client-specific settings

Not every schema key applies to every client. GitHub currently documents OpenTelemetry export for Copilot CLI, Visual Studio Code (VS Code), and JetBrains IDEs, not for the Copilot app or cloud agent. The remoteControl key also has its own client scope. Administrators should use the live support matrix rather than assuming universal enforcement.

For measuring adoption after rollout, the Copilot impact dashboard guide explains what GitHub’s administrative metrics can and cannot establish.

Choose a deployment method

GitHub supports three deployment paths in its enterprise-managed settings guide. All use the same schema, but their operational properties differ.

Server-managed settings

GitHub recommends server-managed settings for most enterprises because the configuration can follow a pull-request and audit-history workflow. An enterprise owner selects an organization containing a .github-private repository, then stores the policy at:

copilot/managed-settings.json

GitHub says the repository applies settings to users on the enterprise Copilot plan even when they cannot read that repository. Its governance repository guide recommends protecting changes with repository rulesets; code-owner review is also a sensible way to assign accountability.

MDM-managed settings

MDM deployment fits enterprises that already target macOS or Windows device groups through tools such as Intune or Jamf. It allows phased assignment to managed devices. GitHub says clients check for updated MDM policy hourly and that VS Code administrators can force a test sync.

File-based settings

File distribution works across platforms and can cover containers or Codespaces where server-managed or MDM deployment is unavailable. Its limitation is coverage: GitHub explicitly says machines that do not receive the file are not restricted by it. File permissions and reliable distribution therefore become part of the control.

GitHub’s documented precedence order is MDM-managed, server-managed, file-based, then user-level settings. A higher-precedence source can override a lower one. Inventory all sources before investigating a value that appears not to match the repository file.

How the cloud agent fits

GitHub’s July 27 announcement says the Copilot cloud agent reads applicable managed settings, including approved plugins and marketplace controls, and observes a change on the next task assignment. GitHub’s current support matrix marks permissions.disableBypassPermissionsMode as supported in Copilot CLI, VS Code, the GitHub Copilot app, and JetBrains IDEs, but not in the cloud agent.

GitHub’s current deployment guide lists Copilot CLI, VS Code, the GitHub Copilot app, the cloud agent, and JetBrains IDEs as supported clients overall, while warning that not every client supports every property. Administrators should verify each key against the live matrix and a controlled task before making a compliance claim.

Cloud-agent access, repository eligibility, firewall configuration, and automations also have separate policies. Do not infer that enabling the desktop app enables every cloud-agent workflow, or that an app marketplace rule supplies all network controls. Teams evaluating autonomous repository work can use the Copilot code review configuration guide to understand adjacent instruction, runner, and firewall boundaries.

What this means

For enterprises already deploying managed-settings.json, the immediate task is validation rather than redesign. Review the default-on app access policy, confirm the existing file contains only intentional settings, and test the app after a restart or sign-in. GitHub says server-managed changes normally arrive within about an hour and can apply immediately after restart or renewed sign-in.

For enterprises starting from scratch, separate the rollout decision into two questions:

Which organizations or users should have the Copilot app?
Which behaviors must be centrally restricted on every approved surface?

Editorial inference: a limited pilot is preferable when plugin policy, permission prompts, or device coverage are not yet defined. GitHub itself recommends piloting managed settings on a small device group before broad deployment. The pilot should test effective policy, not just whether the app launches.

This update does not by itself justify buying more Copilot seats. Teams still comparing coding environments should start with GitHub Copilot vs Cursor and evaluate workflow fit before building enterprise-specific administration around one product.

Adoption decision criteria

Enable the app broadly when the enterprise has reviewed the default, established plugin and approval rules, protected its governance configuration, and confirmed that pull-request controls match the app workflow.

Delegate to organizations when their repository risks and workflows differ, and central policy owners are comfortable with that variation. Document who owns the decision so “Let organizations decide” does not become an unreviewed default.

Disable the app temporarily when administrators cannot identify effective access, required plugins are not vetted, file-based policy misses unmanaged devices, or the organization cannot verify how settings apply to representative users. Disabling the app need not disable the CLI because the policies are now independent.

Verification checklist

Open AI Controls → Copilot Clients and record the effective Copilot app policy.
Check whether the default Enabled everywhere value matches the enterprise’s intent.
Test separately that the Copilot CLI policy has the intended value.
Identify users assigned through organizations and directly through the enterprise.
Inventory MDM, server-managed, file-based, and user-level configuration sources.
Validate managed-settings.json against GitHub’s current schema reference.
Review every enabled plugin and marketplace source, including access to private plugin repositories.
Confirm that approval bypass cannot be enabled when policy requires prompts.
Verify model policy separately if automatic selection is not acceptable.
Protect .github-private changes with review rules and an accountable owner.
Test a supported app version after restart or sign-in and allow for GitHub’s stated hourly refresh.
Run a controlled cloud-agent task before claiming that a particular key is enforced there.
Keep pull-request review, required checks, and repository rulesets in place.

Frequently asked questions

Does disabling GitHub Copilot CLI also disable the Copilot app?

No. Since July 27, 2026, GitHub documents separate policies for the Copilot app and Copilot CLI. Review both controls independently.

Is the GitHub Copilot app enabled by default for enterprises?

GitHub says the dedicated app policy was set to Enabled everywhere by default when released. Administrators should check the current effective policy in AI Controls because later manual or inherited configuration may differ.

Can an organization override enterprise-managed settings?

No for supported managed-settings.json keys. GitHub says those settings apply enterprise-wide with no organization-level override, and a managed value takes precedence over a developer’s local configuration. The separate app access policy can be delegated with Let organizations decide.

Does `disableBypassPermissionsMode` stop all risky actions?

No. It prevents the app’s global Allow all tool-permission setting when configured as documented. Users may still approve individual actions, so repository permissions, secrets handling, network controls, and human review remain necessary.

How quickly do managed-setting changes apply?

For server-managed settings, GitHub says supported clients normally update within about an hour, or immediately after the client restarts or the user signs in again. The cloud agent observes applicable changes on the next task assignment, according to the July 27 announcement.