GitHub 7 月 27 日把 enterprise managed settings 延伸到 Copilot app 與 Copilot cloud agent，讓企業可以用同一份 managed-settings.json 管理不同 Copilot client 的插件、marketplace 與模型政策。這項更新的核心是設定來源與優先順序，不是新增一個模型。
GitHub 的參考文件列出 MDM-managed、server-managed、file-based 與 user-level settings 的優先順序，其中企業管理的設定會壓過使用者在本機寫入的相同欄位。Copilot app 與 cloud agent 現在加入 CLI、VS Code 的治理範圍。
同一份 managed-settings.json 讓企業設定高於使用者本地值
企業政策可以從 server、MDM 或檔案部署到支援的 Copilot client。GitHub 說明，對每一個支援的 key，managed-settings.json 的值會優先於開發者在本地設定的值，因此企業能把插件來源、模型預設與部分權限寫成一致規則。
這個優先順序對 Copilot app 與 cloud agent 特別重要，因為兩者的工作入口不同，但企業不必為每個入口維護完全不同的 JSON。實際支援的欄位仍要依 GitHub 的 managed settings reference 判斷。
enabledPlugins 與 permissions.model 成為企業可配置的模型入口
enabledPlugins 可以指定插件啟用或停用，extraKnownMarketplaces 可以加入可用的插件來源，strictKnownMarketplaces 則能把安裝範圍限制在明列的 marketplace。permissions.model 設為 auto 時，新對話會以 auto model selection 作為預設，但使用者仍可在單一對話指定不同模型。
這些欄位把模型選擇和外部工具來源放在同一份政策中，企業可以依工作類型限制可用模型與插件。GitHub 文件也提醒，插件若來自私有 repository，使用者仍需要取得該來源的授權。
Copilot cloud agent 與互動式 app 的控制範圍不同
bypass-prompt 控制可限制 Copilot app、Copilot CLI 與 VS Code 在執行命令、存取檔案或抓取 URL 前略過核准；GitHub 明確表示這項控制只適用互動式 client，不適用 Copilot cloud agent。
所以同一份設定檔可以同時限制 app 與 cloud agent 的 plugins 和 marketplaces，卻不能假設兩者會顯示相同的核准提示。企業要把 cloud agent 的安全界線放在可用工具、工作指派和執行環境設定上。
GitHub 支援 server、MDM 與 file-based 三種企業部署方式
GitHub 的部署文件提供 server-managed、MDM-managed 與 file-based 方法；server-managed 通常使用企業的 .github-private repository 與 copilot/managed-settings.json。設定更新通常在約一小時內套用，重新啟動 client 或重新登入可立即載入，Copilot cloud agent 則會在下一次工作指派時讀取變更。
消息來源：GitHub Changelog、GitHub managed settings reference、GitHub 部署文件。
