Updated 1 minute ago

Share this article

Related News

Gemini 4 Argon reaches GitHub Copilot with usage-based pricing

Oct 14, 2026

Gemini 4 Argon reaches GitHub Copilot with usage-based pricing

GitHub has made Gemini 4 Argon generally available across eight Copilot clients for Pro+, Max, Business and Enterprise users. Access rolls out gradually, follows model-policy controls and uses per-token AI-credit billing.

GitHub CopilotGemini 4 ArgonAI models

GitHub budgets are now searchable across scopes, products and users

Oct 13, 2026

GitHub budgets are now searchable across scopes, products and users

GitHub has replaced paginated budget hunting with one searchable list for personal, organization and enterprise accounts. Filters can narrow by scope, product, SKU or user, but operators still need to distinguish alerts from hard spending limits.

GitHubbillingAI credits

Six GitHub Copilot models retire October 19: the migration map

Oct 13, 2026

Six GitHub Copilot models retire October 19: the migration map

GitHub will remove six Copilot models on October 19, 2026 and names a successor for each. Teams should inventory pinned model IDs and policy defaults before the deadline because retirement removes access, while replacement enablement still follows organization policy.

GitHub CopilotAI modelsmodel migration

GitHub Copilot can now fail closed when managed settings are stale — Source: GitHub / screenshot captured by OpenToolsSource image

Enterprise AI

GitHub Copilot can now fail closed when managed settings are stale

By OpenTools Team

A new forceRemoteSettingsRefresh control can require Copilot clients to fetch current policy at startup. GitHub is also adding minimum client versions to governance‑sensitive settings, beginning with the sandbox key.

A startup can require fresh policy before Copilot runs

GitHub's October 13 update adds forceRemoteSettingsRefresh for supported Copilot clients. When the value is true, Copilot must retrieve current managed settings at startup instead of accepting a cached policy response.

The control is supported in Copilot CLI, Visual Studio Code and the GitHub Copilot app. It can be delivered through server‑managed settings, mobile‑device management or a file‑based configuration.

This closes a specific gap: a recently changed restriction no longer has to wait for the normal settings cache to expire before it reaches a starting client.

If freshness cannot be confirmed, the client fails closed

With forced refresh active, a cached response cannot satisfy the freshness requirement. GitHub says a client that cannot confirm current policy fails closed instead of starting with stale or unconfirmed settings.

The tradeoff is availability. A GitHub outage, blocked network path or broken identity flow can stop Copilot from starting even when yesterday's cached policy was valid. Without the control, clients keep using the normal cache for faster startup and resilience during transient failures.

Teams should choose based on the consequence of stale policy. A high‑control environment may prefer a predictable stop; a lower‑risk environment may accept a bounded cache window to preserve developer access.

Server‑managed delivery has a first‑start limitation

GitHub distinguishes the delivery channel. MDM‑managed and file‑based settings can require a fresh fetch before a client signs in for the first time. A server‑managed value begins enforcing startup refreshes only after the client has received that value once.

That means a server‑only rollout needs a bootstrap check. Administrators should not infer that an uninitialized device failed closed before its first successful policy synchronization.

GitHub's deployment guide describes the available managed‑settings channels. Record which channel wins, enroll a clean test device and verify behavior both with the policy service reachable and with it deliberately unavailable.

The sandbox key can force outdated clients to update

GitHub is also attaching minimum supported client versions to governance‑focused managed keys, starting with sandbox. When that key is present, users pinned to an older Copilot client must update before they can resume using Copilot.

The rule prevents an old client from silently ignoring a control it cannot enforce. It can also expose unmanaged version pins, slow desktop deployment rings or compatibility freezes.

Before setting the key broadly, inventory client versions and confirm that the approved release is available through every managed channel. Treat an update block as a policy signal, not a reason to remove the sandbox requirement without review.

Test policy freshness separately from telemetry and sandbox behavior

A complete acceptance test has three layers: the client fetched the current settings, the client enforced each governed feature, and the organization received the expected operational evidence. Those layers should be checked independently.

Use a harmless policy delta, capture the resolved managed source, restart the client, and verify the expected allow or deny result. Repeat once with the policy endpoint unavailable to prove the intended fail‑closed or cached behavior. Then restore normal connectivity and confirm recovery.

The new control complements GitHub's earlier fine‑grained Copilot telemetry settings; it does not prove which telemetry fields or sandbox actions occurred. Follow GitHub's OpenTools organization page for further governance changes.

Image: Real screenshot of GitHub's official October 13 managed‑settings release page. OpenTools captured the source page for this report; no generative alteration or artificial upscaling was used.

Sources

1.github.blog (github.blog)
2.docs.github.com (docs.github.com)
3.docs.github.com (docs.github.com)

Tags

GitHub Copilotenterprise governancemanaged settingsAI sandboxdeveloper tools