Weekly GitHub Copilot Roundup: Local Models, Sandboxing, and Governance

by TechHub

Welcome to this week's GitHub Copilot roundup, where the main story is Copilot getting more practical in enterprise settings through on-device models, intelligent routing between local and cloud inference, and generally available local sandboxing powered by Microsoft eXecution Container (MXC). Model choice expanded across Copilot surfaces with Claude Haiku 5.5 going GA and Copilot CLI adding local model discovery via Ollama, making it easier to standardize speed, cost, and privacy defaults across teams. On the governance side, GitHub introduced a purpose-built secret detection model that spans GitHub and Copilot, and added org-level billing and policy controls for Copilot code review so spend and eligibility are easier to manage.

This Week's Overview

Copilot goes local: on-device models and safer tool execution

Building on last week's push toward enforceable agent guardrails (local sandboxing in preview and more governed tool execution), GitHub Copilot added first-class support for on-device AI coding on new Windows PCs, with automatic routing between local inference and the cloud depending on what you are doing and what is available on the machine. The initial local model called out is MAI Code 1.1 Flash, and the direction is clear: run more tasks offline (or at least locally) when it makes sense, and fall back to cloud models when you need broader capability.

At the same time, local sandboxing for Copilot is now generally available in Copilot CLI, the Copilot app, and VS Code Agent Host sessions. Sandboxing is powered by Microsoft eXecution Container (MXC) and lets enterprises enforce policy-based restrictions around what agent tools can access (files, network, and credentials) on developer machines. Together, these updates make “agentic” Copilot features easier to adopt in stricter environments because you can separate model choice from safety boundaries and enforce the latter centrally.

GitHub also previewed “intelligent local model routing” that will automatically discover local models (including Ollama and Microsoft Foundry Local) and offload some tasks to on-device compute for offline usage and for zero AI Credits. If your org is experimenting with Bring Your Own Key (BYOK) models or developer-provisioned local models, this is a signal to start thinking about standardizing how local runtimes are deployed and governed across laptops, not just in CI.

Model choice expands across Copilot surfaces

Following last week's expansion of the Copilot model menu (and the reminder that model policy is now an admin surface), more Copilot experiences are converging on a consistent “pick the right model for the job” workflow, with clearer admin controls and billing implications. This week combined model availability news (a new fast option in the picker) with plumbing work that makes local models easier to discover and switch to from the CLI.

Claude Haiku 5.5 becomes generally available

Claude Haiku 5.5 is now generally available in GitHub Copilot, positioned for fast, high-volume tasks and lower token and step usage based on early testing. Developers can select it from the Copilot model picker where supported, while admins can manage access via model policy and understand how it bills under usage-based pricing.

For teams using Copilot across multiple contexts (chat, agent sessions, and review flows), the practical change is that you can standardize when Haiku is the default choice (speed and cost) versus when you require a larger model for deeper refactors or complex reasoning. If you are tracking spend, this also reinforces that model selection is now a governance surface, not just a personal preference.

Copilot CLI gets local model discovery via Ollama

Building on last week's CLI momentum around making the terminal a first-class Copilot surface, GitHub Copilot CLI v1.0.94-0 can now discover local models from a running Ollama instance using the /model command, with an in-CLI picker that can add models and optionally switch without restarting. The release also clarifies offline mode behavior, telemetry, and provider connection error reporting, which matters when local runtimes fail in ways that look like “Copilot is down” to users.

If you are supporting developers who want local inference for privacy, latency, or travel/offline workflows, this is a tangible usability improvement. It reduces friction from manual config edits and makes it easier to keep a consistent “choose a model” habit across the editor and the terminal.

Security and governance: secret detection and code review cost controls

As last week's governance thread tightened defaults and validation, Copilot and GitHub Advanced Security (GHAS) updates this week focused on two practical admin problems: stopping secrets earlier in the dev flow, and making AI-assisted code review costs predictable. The common theme is moving from “cool feature” to “operational control” across large organizations.

A purpose-built model for leaked secret detection across GitHub and Copilot

GitHub introduced a fine-tuned, context-aware model for leaked secret detection that spans secret scanning alerts, push protection, and GitHub Copilot /security-review. The goal is better detection for unstructured secrets, with clearer boundaries around what is included versus what consumes GitHub AI Credits, and more knobs for admins to budget and control usage across GitHub Enterprise Cloud (GHEC) and GitHub Enterprise Server (GHES).

A companion post frames this as a scaling problem: secret exposure grows with the volume of code pushed, so protection has to work earlier than “after merge” and across more surfaces where code is generated and modified. GitHub called out a fast ModernBERT-based classifier used to expand push protection, and highlighted rollout coverage across cloud, GHES, and Copilot touchpoints (including Copilot CLI /security-review), with GitHub Enterprise Server 3.23 noted in the availability story.

Copilot code review billing and policy controls at the org level

Picking up from last week's push to make Copilot Code Review more configurable and measurable, GitHub Copilot code review added organization-level billing options so you can choose whether review usage bills against a member's Copilot entitlement or the organization's AI Credits budget. It also adds a policy that can restrict review requests to users licensed through the org or enterprise, which reduces surprise spend caused by ad hoc reviewer selection.

This matters most for teams rolling out Copilot code review broadly: you can now align cost attribution with how your company funds AI usage (central budget vs team budgets) while keeping the “who is allowed to request reviews” surface consistent with licensing strategy. If you previously avoided enabling code review due to unclear charging paths, this update is aimed directly at that barrier.

Copilot agent sessions and IDE integrations mature

Building on last week's IDE and agent workflow work (Dev Containers for VS Code, and tighter JetBrains controls), this week's updates tightened the loop between IDE-hosted Copilot experiences and standalone agent runtimes. GitHub is clearly investing in “agent sessions” as a shared capability that can outlive one editor window, while still making sure enterprise teams can manage controls, telemetry, and reliability.

VS Code 1.141: agent host sandboxing, persistent progress, and MCP discovery

Visual Studio Code 1.141 highlighted several Copilot-related improvements, including external session continuation (keeping an agent session going beyond the current VS Code instance), persistent chat progress, and updates around agent host sandboxing. The release also mentioned MCP server discovery, which matters if you are building or consuming Model Context Protocol (MCP) tools and want Copilot to find the right servers without manual wiring.

On the developer workflow side, VS Code also focused on session layout and worktree cleanup/storage reclamation, which pairs with Copilot agent usage because agent-driven workflows often create branches and worktrees rapidly. If your team uses worktrees to isolate experiments, the combination of better cleanup plus longer-lived agent sessions reduces the “AI left a mess behind” problem.

JetBrains plugin: enterprise defaults, diagnostics fixes, and MCP startup control

Following last week's JetBrains 1.18.0 focus on approvals and tighter MCP control, Copilot for JetBrains shipped an update that adds enterprise-managed default agent models, making it easier for admins to standardize the model used by default in corporate environments. It also introduced a diagnostics “Fix” action that opens inline chat, tightening the feedback loop from IDE diagnostics to Copilot guidance.

For teams experimenting with MCP servers, the JetBrains plugin now offers an option to disable automatic MCP server startup, which is useful when developers need explicit control over what local services run (or when an org requires reviewed configuration before tools come online). The release also improves chat and account UX and reliability, and deprecates JetBrains IDE 2025.1 support (moving the baseline to JetBrains IDE 2025.2).

Shared agent runtime across devices (Copilot SDK and Agent Host Protocol)

GitHub demonstrated how Copilot agent sessions can be hosted independently of a single editor and accessed across devices using GitHub's shared agent runtime. The demo referenced the Copilot SDK and the Agent Host Protocol, and showed a Copilot CLI-to-Linux workflow with multiple clients receiving live updates.

If you are building internal tools on top of Copilot or trying to make agent sessions a team resource (not a single-developer artifact), this architecture matters. It points toward workflows where the “agent” is closer to a service with controlled execution and auditing, rather than a feature embedded entirely inside one IDE.

Measurement and evaluation: usage metrics, AX, and a code review benchmark

Continuing last week's theme of making Copilot measurable beyond basic adoption counts (with PR review stages added to usage metrics), this week included a practical fix for usage attribution, plus two pieces of content that push teams toward clearer evaluation of agent behavior and code review quality.

Fixing undercounted agent activity in Copilot usage metrics

GitHub addressed an issue where Copilot SDK-based agent sessions undercounted usage metrics because sessions were not correctly identifying their IDE. The fix requires updating to specific IDE versions to restore correct attribution, and GitHub noted that missing historical data cannot be backfilled.

For organizations using Copilot usage metrics to justify spend, adoption, or compliance, this is a reminder to treat IDE and extension versions as part of your reporting pipeline. If you run periodic audits on tool versions, include Copilot agent mode compatibility and telemetry attribution in the checklist.

Agent Experience (AX) and ReviewBench for code review agents

A new post defined Agent Experience (AX) as a way to measure whether AI agents discover and correctly use your SDKs, APIs, and CLIs, separating propensity (will the agent choose your tool) from efficacy (does it succeed when it tries). It also emphasized measuring both quality and task cost, with examples drawn from GitHub Copilot Chat scenarios, which is useful if you are publishing MCP tools and want evidence they are actually being used correctly.

Separately, GitHub introduced ReviewBench, an open offline benchmark for AI code review agents built from representative GitHub pull requests with multi-source ground truth and calibrated evaluation metrics. It distinguishes grounded scoring from augmented scoring and invites teams to submit agents and publish results on a shared leaderboard, which should help teams compare review agents beyond anecdotal “seems good” testing.

Other GitHub Copilot News

Copilot education and demos this week continued to center on agent workflows, MCP-based tool building, and practical ways teams integrate Copilot into real delivery processes.

A couple of smaller items are worth a quick skim if they match your environment: one troubleshooting post on Windows 11 performance (and the security tradeoffs of Defender exclusions), and two lighter workflow pieces about hackathons and a VS Code Chat slash command.