# GitHub Extends Enterprise Managed Settings to the Copilot App and Cloud Agent

**GitHub now applies the same enterprise managed settings used for Copilot CLI and VS Code to the Copilot app and the Copilot cloud agent.**

## What changed
GitHub said enterprise owners can now govern the Copilot app and the Copilot cloud agent with the enterprise managed settings they already use for Copilot CLI and VS Code. A managed-settings.json file defines the guardrails once, and every supported client enforces them for everyone on the enterprise's Copilot plan. The [GitHub Changelog](https://github.blog/changelog/2026-07-27-enterprise-managed-settings-now-apply-to-the-github-copilot-app/) post frames this as closing a gap left by any client that previously sat outside enterprise policy.

## What the policy controls
The Copilot app reads the same managed-settings.json file enterprise owners already maintain for their other clients. Owners can use it to restrict Copilot to an approved list of plugins, limit developers to specific plugin marketplaces, decide whether a developer can skip the confirmation step before Copilot executes a command, touches a file, or reaches out to a URL, and choose whether auto model selection is switched on for new conversations by default. The Copilot cloud agent picks up the same managed settings, including its plugin and marketplace rules, but only runs plugins and marketplaces an enterprise has already approved. The confirmation-step control only applies to the interactive clients — the app, Copilot CLI, and VS Code — because the cloud agent has no interactive prompt to skip.

## Rolling it out
If an enterprise already deploys managed-settings.json for Copilot CLI and VS Code, nothing new needs to be configured. The Copilot app picks up the existing configuration the next time a developer signs in or restarts the app, and the cloud agent observes changes on its next task assignment. For a first-time setup, GitHub points enterprise owners toward server-managed deployment: create a .github-private repository, add or update a copilot/managed-settings.json file inside it, and push the enterprise's policy keys and values to the default branch. Enterprises can also push settings through MDM or a distributed file instead of the repository route.

## Why it matters
Any client sitting outside an enterprise's Copilot policy is a place where a developer could install an unvetted plugin or run a command the enterprise would normally gate. Bringing the Copilot app and cloud agent under the same managed-settings.json file means an enterprise's governance now follows developers into every surface where they use Copilot, instead of covering only the CLI and VS Code.

## Key facts
- Enterprise managed settings now cover four Copilot clients: the Copilot app, Copilot cloud agent, Copilot CLI, and VS Code.
- Settings live in one managed-settings.json file, set up through a .github-private repository at the path copilot/managed-settings.json.
- Managed settings can restrict plugins, restrict plugin marketplaces, control the confirmation-step bypass, and set auto model selection as default.
- The confirmation-step control applies only to interactive clients — the app, Copilot CLI, and VS Code — not the cloud agent.
- Enterprises can also push settings through MDM or a distributed file instead of the server-managed repository.

## Check your understanding
Which four Copilot clients does GitHub say now read the same managed-settings.json file?
Why does the confirmation-step control apply only to the interactive clients and not the cloud agent?

## Sources
- [GitHub Changelog](https://github.blog/changelog/2026-07-27-enterprise-managed-settings-now-apply-to-the-github-copilot-app/)

---

- Category: implement (tooling)
- Affects: —
- Published: 2026-07-27T00:00:00.000Z
- Original: https://github.blog/changelog/2026-07-27-enterprise-managed-settings-now-apply-to-the-github-copilot-app/
- Generated by tinker news