GitHub has announced two updates to enterprise managed-settings enforcement: administrators can require supported Copilot clients to retrieve current server-managed policy at startup, and the sandbox managed-settings key now includes minimum client-version enforcement. The changes affect Copilot CLI, the GitHub Copilot app, and VS Code, and are intended to reduce inconsistent behavior caused by stale policies or outdated clients.
For administrators, the main operational change is a trade-off: enabling required refreshes removes the convenience of relying on cached settings when current policy cannot be confirmed. Teams will need to account for startup network access, deployment timing, and client update requirements.
What changed
The new forceRemoteSettingsRefresh setting can be configured as true to require supported Copilot clients to retrieve and confirm current server-managed settings when they start. When the requirement is active, a cached response is not sufficient.
If the client cannot confirm the current policy, it fails closed instead of continuing with an older or unconfirmed configuration. According to GitHub’s Copilot CLI changelog and the managed-settings reference, the detailed behavior varies by client:
- Copilot CLI and the GitHub Copilot app skip the normal one-hour cache and do not fall back to an older cached policy when a required refresh is active.
- VS Code blocks Copilot features until the required refresh succeeds.
- Users subject to the requirement need network access at startup.
Without forceRemoteSettingsRefresh, the usual managed-settings caching behavior remains available. That can provide faster startup and continued resilience during temporary service failures, but it also means a client may not immediately reflect a newly changed policy.
The second update applies to the sandbox managed-settings key. Covered clients must meet the applicable minimum version before they can continue using Copilot with that setting. The available documentation identifies Agent Host version 1.138.0 or later in the sandbox support information, but it does not establish that number as the minimum version for every Copilot client. Administrators should therefore avoid applying it as a universal client-version requirement.
Deployment method determines when enforcement starts
The timing of enforcement depends on how the managed setting reaches the device. GitHub’s managed-settings deployment documentation describes three delivery methods: server-managed, MDM-managed, and file-based settings.
MDM-managed and file-based settings can apply the refresh requirement before a user signs in for the first time. This makes those methods the relevant choice when an organization needs the rule to be present from the device’s first Copilot startup.
A server-managed value behaves differently. The client must first receive that value. The refresh requirement then applies on subsequent startups rather than retroactively affecting the first startup before the setting has been delivered.
The methods also differ in platform and licensing scope. Native MDM delivery is documented for Windows and macOS, while file-based settings are available across the listed macOS, Windows, and Linux environments, including environments such as containers and Codespaces. Server-managed settings apply to users who receive a Copilot license from the enterprise. MDM-managed and file-based settings apply to the user regardless of where that user’s Copilot license is received.
These distinctions are not a complete eligibility or licensing matrix for forceRemoteSettingsRefresh. They are deployment characteristics administrators should consider when choosing how to distribute the policy.
Configuration details administrators should check
In managed-settings.json, configure forceRemoteSettingsRefresh as the JSON Boolean true:
{
"forceRemoteSettingsRefresh": true
}There is an important format distinction for Copilot CLI configurations. In Windows registry and macOS managed-preference configurations, the value must be stored as a string containing true or false, not as a DWORD or native Boolean. Native MDM values are strings more generally; booleans, arrays, and objects are represented as JSON text inside those strings.
Policy helper scripts cannot set forceRemoteSettingsRefresh, so administrators should use one of the supported managed-settings delivery methods instead.
Settings precedence is also relevant when multiple sources are present. The documented order is MDM-managed settings, server-managed settings, file-based settings, and then user-level settings. Sandbox and certain permissions-related keys can be composed in the most restrictive direction, so administrators should review the documented behavior rather than assume that every key follows simple replacement semantics.
Why the change matters to engineering teams
Startup freshness enforcement can make policy changes take effect more consistently across developer workstations. It also changes the failure mode. A workstation with no startup network access, or one affected by a temporary service problem, may no longer start the affected Copilot functionality with its last known policy.
That behavior may be appropriate for organizations that prioritize confirmed policy over offline or degraded startup. It can be disruptive for teams that depend on uninterrupted development sessions, particularly if the requirement is deployed without first checking connectivity and client coverage.
The sandbox version requirement creates a separate coordination problem. Updating a managed-settings file or MDM profile may expose older clients to a rule they cannot satisfy. The supplied sources do not document the exact update prompt, download process, or error flow for blocked users, so administrators should not assume how the client will guide an upgrade. A client inventory and an update plan are safer prerequisites.
Local sandboxing itself is generally available in Copilot CLI, the GitHub Copilot app, and VS Code sessions using Agent Host. The associated restrictions can cover command execution, filesystem and network access, credentials, and supported local MCP and language-server access. That general availability should not be confused with a fully documented minimum-version matrix for every client using the sandbox managed-settings key.
What you should do
- Choose the required enforcement point. If policy must apply before first sign-in or on the first device startup, evaluate MDM-managed or file-based delivery. Use server-managed delivery when the enterprise-controlled setting can begin applying after the client has received it.
- Plan for startup connectivity. Users subject to
forceRemoteSettingsRefreshneed network access when the client starts and must be able to confirm current policy. - Validate the value format. Use the JSON Boolean in
managed-settings.json. For Copilot CLI Windows registry and macOS managed-preference configurations, use the string representation rather than a native Boolean or DWORD. - Inventory sandbox-enabled clients. Check the versions of Copilot CLI, VS Code, the GitHub Copilot app, and Agent Host where applicable. Do not treat Agent Host 1.138.0 as a confirmed minimum for every client.
- Coordinate policy and client rollouts. Update older clients before or alongside deploying the sandbox requirement to reduce interruptions.
- Review precedence and scope. Confirm whether MDM, server-managed, file-based, or user-level settings are supplying each relevant key, and account for the different platform and licensing characteristics of each delivery method.
Availability and remaining limitations
GitHub’s October 13, 2026 announcement covers the enforcement updates, while the deployment documentation supplies the operational details for first-startup behavior, delivery methods, precedence, and supported platforms. The local sandboxing announcement on October 7, 2026 describes sandboxing as generally available in the listed Copilot experiences.
The supplied documentation does not provide exact release versions for forceRemoteSettingsRefresh support in each client, a complete sandbox minimum-version matrix, or a complete region and plan matrix for the refresh setting. Administrators should verify those details through their applicable GitHub documentation and client rollout process before making them deployment assumptions.
