Weekly GitHub Copilot Roundup: Agents Expand, Controls Catch Up

by TechHub

This week's Copilot story was less about one headline and more about Copilot being available in more places: stronger agent controls in VS Code and GitHub Mobile, deeper terminal workflows through Copilot CLI (including offline/BYOK), and more admin/reporting to track adoption and outcomes. It follows last week's theme that as Copilot grows from chat/autocomplete into branch/PR agents, multi-agent CLI orchestration, and MCP-backed tooling, GitHub is closing gaps in control (permissions, firewall/runner placement), traceability (sessions/logs/telemetry), and administration (instructions and usage reporting).

Copilot in VS Code: more autonomous agents, richer debugging, and better customization

Building on last week's VS Code work (session restore with diffs/undo, background terminal completion notices, integrated browser context, and SSH agent host mode), the March-early April releases (v1.111-v1.115) expanded agent sessions, starting with per-session Agent permissions to control autonomy. Sessions can run as Default, Bypass Approvals, or Autopilot (public preview). Autopilot lets the agent approve its own actions, retry on errors, and continue until completion, so you can run longer multi-step work with fewer prompts when that fits the task. It continues the “resumable and auditable sessions” direction from last week, but with an explicit autonomy choice up front. VS Code workflow changes also go beyond agents. The editor now supports integrated browser debugging through a new editor-browser debug type that works with many existing Chrome/Edge configurations. With self-signed cert support for local HTTPS and improved tab management (Quick Open, Close All, title-bar shortcuts), web debugging can happen with fewer context switches. This connects to last week's “integrated browser as session context” idea: debugging context and “agent saw these tabs” are starting to land in the same editor-native loop. On models, reasoning models now have a persistent “thinking effort” control in the model picker (for example, Claude Sonnet 4.6 and GPT-5.4). That makes it easier to trade speed/cost for deeper reasoning depending on the task. It mirrors last week's model churn point: explicit, repeatable per-session settings (and now “effort”) help teams keep outcomes steadier as model options change. Copilot Chat also gained more multimodal support: you can attach screenshots and videos, and agents can return images/recordings in a carousel (zoom/pan/thumbnails). That is useful for UI bugs and visual diffs, and it extends last week's “blob attachments” work in the Copilot SDK preview. Extensibility and team-scale management also moved forward. Nested subagents can invoke other subagents (chat.subagents.allowInvocationsFromSubagents), MCP integration has better parity (MCP servers configured in VS Code are available to Copilot CLI and Claude agent sessions), and session forking makes it easier to try alternatives without losing the original thread. Customization and diagnostics improved as well: a Chat customizations editor (preview) centralizes instructions/agents/skills/plugins plus marketplace browsing, the #codebase tool moved to one auto-managed semantic index, and /troubleshoot can analyze agent debug logs (including past sessions) to explain issues like ignored instructions or slow responses. Security and governance also improved with sandboxing for local MCP servers (macOS/Linux), better monorepo discovery for shared instructions/agents/hooks, and agent-scoped hooks (preview) via YAML frontmatter in .agent.md. Overall, this reads like the IDE-side follow-through on last week's scaling story: last week expanded repo/org instruction patterns, and this week makes them easier to manage, safer to run, and easier to debug in VS Code.

Copilot CLI: BYOK/local models, cross-model review, plugins, and MCP tool connections

This week's Copilot CLI updates extend last week's “CLI as an agent runtime” direction, where /fleet introduced multi-agent orchestration and the Copilot SDK standardized sessions, tool invocation, and tracing. The CLI is moving from “Copilot in the terminal” to a configurable, extensible agent platform with review flows. The main change is that Copilot CLI now supports BYOK providers and fully offline local-model workflows. You can route to providers you already use (Azure OpenAI, Anthropic, OpenAI-compatible endpoints) or run locally (Ollama, vLLM, Foundry Local). For regulated or restricted environments, COPILOT_OFFLINE=true prevents any GitHub server contact (telemetry disabled) and forces the CLI to use only the configured provider, which helps avoid accidental cloud fallback. GitHub sign-in is optional under BYOK, though GitHub-backed features (like /delegate, Code Search, and the GitHub MCP server) still require GitHub connectivity and identity. The CLI also will not silently fall back on invalid configuration, which helps keep CI and locked-down machines more predictable. In practice, last week's “agent sessions need controls” now includes provider/connectivity control, not only model choice. For developers testing BYOK, the LM Studio walkthrough makes the “local OpenAI-compatible endpoint” path concrete and calls out a common pitfall: if you do not set COPILOT_OFFLINE=true, you may still allow cloud routing. The Azure AI Foundry (Azure OpenAI) setup shows the hosted alternative with its own details: you must use the deployment-scoped URL (.../openai/deployments/<deployment>/v1) and set COPILOT_MODEL to the deployment name, not the catalog model name. This “details matter” theme matches last week's /fleet guidance (separate contexts, shared filesystem, collision avoidance). As CLI use becomes more agent-driven, configuration edge cases matter as much as prompting. For agent quality, Copilot CLI added an experimental “Rubber Duck” workflow that reviews an orchestrator model's output using a different model family at checkpoints (plan review, post-implementation review, test review, or when stuck). In the current experiment, using a Claude model as orchestrator triggers GPT-5.4 as reviewer. The goal is to catch plan mistakes and cross-file edge cases earlier in longer runs without constant interruption. This pairs with last week's “plan first” additions (cloud agent drafting plans, SDK demo emphasizing iterative planning). Rubber Duck turns the “builder vs critic” idea into a structured flow by separating models. The “GitHub Checkout” episode added more context on the CLI's experimental direction: plugins and a plugin marketplace, /chronicle for capturing “self-healing” task context across longer runs, and background execution like /fleet and “autopilot” for wider refactors. For tool integration, the beginner MCP episode focuses on using /mcp with local/remote MCP servers (for example, Playwright and Svelte) so Copilot CLI can invoke tools in an iterative loop rather than only suggesting commands. This continues last week's MCP thread (tools + enforcement + audit) but shifts emphasis from “connect tools” to “make the terminal agent reliably use them.” Finally, the “Copilot CLI for Beginners” post reiterates the core workflow: install (npm install -g @github/copilot), /login, folder permissions, and /delegate to hand a task to the cloud agent to work in a branch and open a draft PR. That sets up the deeper BYOK/MCP/agent features described above. The tie to last week's branch-first cloud agent story is explicit: the CLI is increasingly the “remote control” for branch/PR agent workflows, now with more options for models and tools.

MCP and agent UI inside Copilot: interactive apps, dashboards, and Azure execution guardrails

This month's MCP work moved in three directions: interactive UI inside Copilot Chat, MCP as a deployment surface, and MCP as a governance boundary for infrastructure actions. It continues last week's MCP narrative (connect tools, then operationalize with versioned config and constrained capabilities), with more attention on what users can see in the client and how ops teams can bound what agents are allowed to do. For “UI inside chat,” the Azure App Service tutorial walks through building an MCP App that pairs tools with UI resources so clients like VS Code Copilot Chat can render an interactive widget inline (also compatible with Claude Desktop and ChatGPT). The sample is an ASP.NET Core/.NET 9 MCP server with a weather tool. UI is delivered via a ui:// resource and returned via MCP UI metadata (_meta.ui.resourceUri) plus text/html;profile=mcp-app. It covers packaging tool + UI, running locally through .vscode/mcp.json, and deploying with azd up to App Service using Bicep templates, including App Service settings that matter for interactive calls (Always On, Easy Auth with Entra ID, deployment slots, Application Insights). It also links back to last week's azd “Set up with GitHub Copilot” work: azd is becoming a common path for scaffolding and shipping MCP-backed agent apps. For “visual output,” Visuals MCP added a chart tool that can render charts or multi-card dashboards in Copilot Chat in VS Code, with Storybook examples for payload validation. With support for line/bar/area/pie/scatter/composed charts, layouts, legends/tooltips/gridlines, dual-axis, theme awareness, and CSV/JSON plus JPG/SVG exports, teams can keep analysis and visualization inside the editor. This complements last week's “deep research” and “cited Markdown report” patterns: once research outputs become artifacts, charts and dashboards are a natural next step for reviewable results without leaving the session. For “platform actions with guardrails,” the platform engineering walkthrough shows Copilot agents packaged in a repo (Azure's git-ape) and wired to the Azure MCP Server so agents execute Azure workflows through an explicitly enabled surface. The example runs Azure MCP in namespace mode, allows writes (azureMcp.readOnly: false), and whitelists services like deploy, group, subscription, functionapp, storage, sql, and monitor. That reinforces a pattern where natural-language infra work flows through constrained, reviewable capabilities. This matches last week's governance framing (versioned playbooks and enforcement) and mirrors GitHub-side guardrails (cloud agent firewall and runner controls): agents can act, but only through explicitly allowed surfaces.

Copilot agents in GitHub workflows: mobile coding, faster validation, and security remediation loops

This week's workflow updates follow directly from last week's GitHub.com cloud agent changes (branch-first work without opening a PR, plan-first and deep research sessions, commit signing, plus org firewall/runner controls). The agent is quicker at completing safety checks, fits better into security remediation, and is accessible from more places, especially mobile. GitHub tightened the “agent wrote code” to “safe to merge” loop. Copilot cloud agent validations now run about 20% faster by running checks in parallel: CodeQL, secret scanning, GitHub Advisory Database checks, and Copilot code review. That shortens iteration time without changing what is enforced, and repo owners can still tune validations in Copilot → Cloud agent settings. Combined with last week's session logs/validation traceability and signed commits, this helps agent work fit more naturally into normal CI timing. For remediation, Dependabot alerts can now be assigned to AI coding agents from an alert detail page. The agent reviews the advisory and repo usage, opens a draft PR with a fix, and tries to resolve test failures. Teams can assign multiple agents in parallel to compare approaches (upgrade paths, breaking-change refactors, or downgrades when no patch exists). The intent stays the same: the output is a PR for humans to review. This complements last week's in-IDE remediation note (Visual Studio fixing vulnerable NuGet packages) by moving the loop directly into the security product. Copilot also expanded into mobile. GitHub Mobile now supports a cloud agent flow to research a repo, draft a plan, apply changes on a branch, review diffs, and optionally open a PR from the app. It extends last week's branch-first workflow and makes small fixes and follow-ups more realistic away from a laptop, especially with last week's mobile session logs and issue-based agent assignment.

Other GitHub Copilot News

Copilot adoption and governance became more measurable for admins through several usage metrics API updates. This continues last week's admin thread (org-wide custom instructions GA; per-user Copilot CLI activity in org reports) but shifts from “who used Copilot?” to “which workflows changed, and what happened?” Copilot CLI activity is now included in totals and feature breakdowns (feature=copilot_cli), which simplifies reporting but means dashboards that assumed totals were IDE-only may need updates to avoid double counting. The API also adds merged PRs that were Copilot-reviewed and median time-to-merge for Copilot-reviewed PRs, which moves measurement beyond “Copilot created PRs” to “Copilot reviewed PRs.” For maturity tracking, user-level reports now split active vs passive Copilot Code Review, and enterprise/org reports add daily/weekly/monthly active user counts for the renamed Copilot cloud agent (with null-vs-0 behavior ETL needs to handle). Together with last week's CLI activity reporting, it is easier to separate chat usage, terminal automation, and agent execution in rollups.