The report
GitHub introduced an opt-in rule that can stop Copilot clients from starting when they cannot confirm the latest enterprise policy. Announced on October 13, forceRemoteSettingsRefresh applies to supported Copilot CLI, VS Code and Copilot app clients. Under the rule, a previously cached policy does not satisfy the requirement to fetch current managed settings; an unsuccessful refresh fails closed.
The GitHub changelog makes a useful deployment distinction. A setting supplied through MDM or a managed file can take effect before first sign-in. A server-delivered setting cannot require a fresh fetch until the client has successfully received it at least once, so it applies on subsequent startups. Without the opt-in rule, the normal cache remains available. GitHub also added minimum supported client-version enforcement for the managed sandbox setting, limiting attempts to escape current governance by pinning older client versions.
What the availability trade-off buys
A fail-closed startup removes the window in which an offline or disconnected client silently continues under an obsolete allowance after an administrator changes the server-side rule. The cost is that a legitimate offline agent may also be unable to start. The enterprise must decide whether that restriction fits its operational risk, not assume that every cached configuration is necessarily unsafe.
The policy-boundary Case records the supported scope. GitHub's announcement establishes a control and its stated failure behavior, not an independent audit against tampered clients. A proper deployment test should distinguish first enrollment, policy changes after enrollment, lost network access and an intentionally outdated sandbox client. Those are different routes through the same governance system.