Enterprise Copilot clients can require fresh policy and fail closed when it is unavailable

On October 13 GitHub introduced forceRemoteSettingsRefresh for supported Copilot CLI, VS Code and Copilot app clients. When an enterprise admin activates it, a client must download current remotely managed settings at startup instead of trusting cached restrictions. If the refresh fails, the managed policy is treated as unconfirmed and the client fails closed. This also creates a deliberate availability trade-off for offline clients.

A new client-version floor applies to the managed sandbox key, preventing enterprise users from continuing with an old agent version to escape a new sandbox requirement. GitHub distinguishes first startup: a server-managed flag only applies after its first successful fetch, while MDM/file delivery can enforce freshness immediately. The announcement describes a control feature rather than proof all enterprise installations enabled it or withstand every bypass.

Freshness and enforcement are different properties. A client that successfully received a policy yesterday may still have cached rules today; enabling forceRemoteSettingsRefresh changes its startup decision if the current policy cannot be retrieved. For remote-managed clients, however, the freshness requirement itself has to be delivered once before it can govern a first startup. A locally delivered or MDM-managed rule can close that bootstrap gap at the price of denying legitimate work during network outages. Tests should distinguish first launch, later refresh and deliberately pinned old client versions.