GitHub Copilot's enterprise managed-settings.json is now GA

GitHub moved its enterprise managed-settings.json to general availability on July 1, giving GitHub Enterprise Cloud admins a single JSON file that overrides Copilot behaviour in VS Code and Copilot CLI for anyone holding a Copilot Business or Copilot Enterprise seat issued from the enterprise or one of its organizations.

The changelog frames it as a place to define AI standards for the tenant. In practice it is a supported home for Copilot policy that shipped one setting at a time in beta up to this point.

The five keys the file accepts

Five keys are documented at GA:

• extraKnownMarketplaces
• enabledPlugins
• strictKnownMarketplaces
• disableBypassPermissionsMode
• model

Together they configure trust for extra plugin marketplaces, the enabled-plugins list, strict enforcement of the known-good marketplace list, whether Copilot CLI and the VS Code extension can run in bypass-permission mode, and which model a user is allowed to pick. Value shapes are not enumerated in the changelog itself; the docs page is the reference for the schema.

How the file reaches a client

The file lives at copilot/managed-settings.json inside the .github-private repository of the organization the enterprise nominates for the role. There is a backward-compatible path at .github/copilot/settings.json for tenants already using the older layout.

Copilot clients fetch the file from the server on every authentication, hold it in memory, and refresh it hourly, per the changelog. That server-side file takes precedence over the file-based config a user may have on their own machine.

Setup runs through the AI Controls tab in enterprise settings, or the equivalent API endpoint, where an admin picks the hosting organization. Anyone who followed the June rollouts of disableBypassPermissionsMode and strictKnownMarketplaces will recognise the same file and the same repo. GA is what turns the plumbing into a supported product surface.

Where it will trip you

Two operational details are worth planning around before rollout.

First, the hourly refresh. If policy needs to take effect faster than an hour, expect lag: an engineer sitting inside a long VS Code session may not pick up a rule you tightened at 09:00 until 10:00. Auth events pull fresh, so a re-login shortens the window, but you cannot count on every developer logging out on cue. That cadence is fine for most controls and painful for the ones you would push in response to an incident.

Second, the scope. Enforcement kicks in when the user's Copilot licence is issued by this enterprise or one of its organizations. A personal Copilot seat on the same laptop is outside the boundary. So are the other coding agents the developer has installed alongside Copilot, the MCP servers on their machine, and any homegrown wrappers around a model API. Governance for those still sits with whoever runs them.

The bit that matters for CI

The reason platform teams should care is not the five keys in isolation. It is that the file lives in a repository the org already governs. If the .github-private repo is under the same code-review and approval rules as the rest of your policy-as-code, tightening a Copilot control is now the same motion as tightening any other org setting. If that repository has a quiet blanket bypass, so does every one of these keys.

Which of those two shapes the file takes is the more consequential decision for the next year. The five keys are the starting inventory. The hourly refresh and the licence-scope boundary decide how much reach the file actually has.