Weekly GitHub Copilot Roundup: Desktop app, ops-ready agents

by TechHub

This week in GitHub Copilot, the story is less about new prompts and more about where agent work runs, how it gets reviewed, and how teams operate it safely. The Copilot desktop app expands in preview with canvases, voice input, isolated worktrees, and sandboxes, pushing agent workflows into a separate, reviewable workspace outside the editor. On the ops side, agentic workflows can now use GITHUB_TOKEN instead of PATs, Copilot Chat on the web surfaces cloud agent sessions and searchable history, and Copilot CLI and Code Review add configuration and governance controls (plus a new terminal security review command). We also saw Copilot features land deeper in Azure DevOps and Azure Repos, and model and platform news (Claude Fable 5 in Foundry) that reinforces how much governance, monitoring, and cost controls shape real agent adoption.

This Week's Overview

GitHub Copilot app: desktop workflows move out of the editor

GitHub expanded the technical preview of the GitHub Copilot desktop app, leaning into a pattern that shows up across Copilot tooling this year: put agent work in an isolated, stateful workspace that is easier to review before anything touches your repo (a natural complement to the VS Code Agents window and worktree-based agent flows we covered last week). New additions called out this week include “canvases” for longer-form planning and iteration, voice support for hands-free prompting, isolated Git worktrees to keep agent changes separated, and secure sandboxes to reduce risk when running or testing AI-suggested changes locally.

The app is positioned as something you can use alongside your editor, not just in it. It is now available to anyone on a paid Copilot plan, which makes it easier for teams to standardize on one “out of band” place to run investigations, draft changes, and then merge them back via a review step rather than inline edits.

Agentic Copilot gets more “ops-ready”: auth, observability, and orchestration

This week’s Copilot updates put a lot of emphasis on running agents safely at scale: fewer secrets, more visibility into what an agent did, and better control over where the work runs. The changes span GitHub Actions-backed workflows, Copilot Chat on the web, and the Copilot CLI's orchestration behavior.

Agentic workflows can use GITHUB_TOKEN (no PAT required)

GitHub Agentic Workflows can now authenticate using GitHub Actions' built-in GITHUB_TOKEN instead of requiring a personal access token (PAT), which builds on last week's tools-and-permissions focus by letting teams keep agent auth inside the same least-privilege controls they already use for Actions. For teams, this reduces the overhead of token provisioning and rotation, and it aligns agent execution with existing workflow permission controls rather than developer-owned secrets.

The update also enables org-owned repositories to bill Copilot CLI usage directly to the organization when the right Copilot policy and workflow permissions are set. The changelog specifically calls out needing workflow permissions like copilot-requests: write, which is an important detail for anyone tightening least-privilege on Actions workflows.

Copilot Chat on the web can follow cloud agent sessions (and search history)

Copilot Chat on GitHub now reflects in-progress cloud agent sessions, and it supports follow-up questions after the session completes, extending last week's thread about longer-running sessions you can supervise across devices into a web-native place to review and continue the work. GitHub also added ways to pull agent logs into chat and search or summarize past agent sessions, which helps when you need an audit trail or want to reuse prior work without re-running an agent.

In practice, this is a step toward treating agent runs as first-class artifacts: something you can inspect, query, and reference later (similar to CI logs). If you are introducing agents into team workflows, these controls make it easier to review what happened and to debug failures when the agent output does not match expectations.

Copilot CLI orchestration: more selective delegation for reliability

GitHub shipped a production change that makes Copilot CLI more selective about delegating work to subagents, a practical follow-on to last week's push for more predictable behavior via better memory/instructions and clearer session management. The goal is to reduce unnecessary handoffs that can slow down runs or introduce failure points, which should translate into more predictable “agent trajectories” (the sequence of steps and tools an agent uses to complete a task).

The post is notable because it describes both offline and online evaluation, including rollout validation, rather than treating agent behavior changes as purely qualitative. If you build internal agent workflows, it is a useful reference for how to measure orchestration changes with A/B testing-style discipline.

Copilot CLI and Copilot Code Review: more configuration and security tooling

Alongside the agentic workflow changes, GitHub added more “day 2” controls to Copilot CLI and Copilot Code Review. The theme is tightening governance (what runs where, what content is allowed) while adding practical tooling that fits into terminal-first workflows.

Copilot CLI: centralized configuration with /settings and a new /security-review command

Copilot CLI now includes a /settings command that centralizes configuration behind a schema-driven interface, continuing last week's direction of making CLI-based agent sessions easier to operate consistently across a team (not just per-developer dotfile tweaks). It supports an interactive dialog, inline updates, reset-to-default behavior, tab-completed keys, and schema validation, which should make it easier to manage team guidance without everyone maintaining ad-hoc dotfile tweaks.

GitHub also introduced an experimental public preview /security-review command that analyzes local code changes and returns security findings with severity and confidence scores. Because it runs in the terminal against what you changed locally, it can act as a quick pre-flight check before you push or open a pull request.

Copilot Code Review: runner controls, content exclusions, and larger instruction files

GitHub added new configuration options for Copilot code review, including org-level controls for what runner types can execute reviews (GitHub-hosted, self-hosted, or large runners), which mirrors last week's theme of treating agent capabilities like managed infrastructure (with explicit boundaries) rather than a per-user feature. This matters for regulated environments where “where the code goes” is as important as the review output, and it lets platform teams align Copilot reviews with existing Actions runner policies.

The update also expands Copilot content exclusions across repository, organization, and enterprise scopes, and it removes the prior 4,000-character limit for instruction files. That last change is a quiet quality-of-life improvement for teams maintaining detailed review guidance, secure coding rules, or architectural constraints as instruction text.

Copilot and Azure DevOps: Autofix and code reviews arrive for Azure Repos

Microsoft continues to pull Copilot capabilities into Azure DevOps workflows, which is important for organizations that standardize on Azure Repos and Azure Pipelines instead of GitHub-hosted repos. Two previews this month focus on security remediation (Autofix) and PR review assistance (Copilot code review), with both using token-based billing and Azure subscription chargeback patterns.

Copilot Autofix (private preview) for GitHub Advanced Security for Azure DevOps

Copilot Autofix is in limited private preview for GitHub Advanced Security for Azure DevOps, generating AI-suggested fixes for supported CodeQL alerts, and it extends last week's “agents need validation gates” storyline by keeping fixes reviewable in PRs instead of applying changes directly. The intent is to move from “findings” to “patches you can review,” with fixes flowing through pull requests so they still fit normal code review controls.

Billing is token-based via GitHub AI credits charged to Azure, which means security teams and platform owners should plan for usage monitoring in Azure Cost Management. The preview details setup steps and scope, so teams can assess whether their CodeQL coverage and alert types match what Autofix currently supports.

Copilot Code Reviews (public preview) for Azure Repos pull requests

Copilot code reviews are now available in limited public preview for Azure Repos PRs, which pairs with last week's work on repository-level instructions by giving teams another place to standardize review expectations and make agent output easier to trust. The announcement includes setup and usage flow, along with preview limits, which is helpful if you need to pilot it with a few repos before rolling out broadly.

Like Autofix, the preview uses token-based billing with GitHub AI credits charged back to an Azure subscription. That chargeback model is a practical detail for enterprises because it changes who “owns” Copilot costs when Copilot is embedded into existing ALM tooling rather than used by individual developers.

Models and platforms: Claude Fable 5 lands in Foundry with Copilot agent support

Anthropic's Claude Fable 5 is now available in Microsoft Foundry, and Microsoft is positioning it for long-running autonomous agent workflows through Foundry Agent Service and GitHub Copilot, continuing last week's theme that model choice is becoming an administrated dependency (with enterprise controls) rather than an individual preference. The announcement highlights multimodal capabilities, enterprise guardrails and observability in the Foundry Control Plane, and token-based pricing, which signals a focus on controlled deployment rather than “chat in a box.”

For developers building agents that run beyond short interactive prompts, the practical takeaway is that the platform story (agent runtime, governance, monitoring, and pricing) is becoming as important as the model choice. Teams evaluating Copilot-backed agents should pay attention to how Foundry’s control plane and agent service map to their compliance and cost requirements, especially when agents run continuously or across larger codebases.

Other GitHub Copilot News

A few additional items this week are worth bookmarking because they either improve safety around non-Copilot agents or show where Copilot context is heading inside editors.

GitHub made security validation for third-party coding agents generally available, applying the same automated checks used for Copilot cloud agent PRs (CodeQL, dependency checks against the GitHub Advisory Database, and secret scanning), which fits as a direct continuation of last week's MCP/tools-and-permissions emphasis by extending guardrails beyond Copilot to the broader agent ecosystem. Validations are enabled by default via Copilot settings, so teams should review settings and expectations for agent-generated pull requests.

VS Code content this month continued to flesh out “agent mode” ergonomics and richer context capture, including updates highlighted for VS Code 1.124 and an Integrated Browser feature that can bookmark sites, capture screenshots, and feed browser content into Copilot and agent workflows, building on last week's Agents window/session ergonomics work by adding more structured ways to bring external context into an agent run. If you rely on agents to work from live docs or web UIs, these editor-side context pipelines can reduce copy/paste and make sessions more reproducible.

On the workflow side, people are sharing more concrete patterns for getting better outcomes from agent mode, from using MCP (Model Context Protocol) servers in VS Code (GitHub, Playwright, and Microsoft Learn) to tuning skills to reduce token waste, which continues last week's pattern of grounding and tool wiring as the main drivers of reliability. These are good reminders that agent performance often depends more on context quality and tool wiring than on prompt phrasing.

Finally, GitHub's May 2026 availability report included Copilot agent/session outages among nine incidents, plus follow-up reliability work like improved throttling, monitoring, and failover guardrails, reinforcing last week's point that long-running sessions and remote supervision only work if the underlying cloud agent runtime is dependable. If your team is adopting cloud agents for production work, these reliability notes are useful input for setting expectations and deciding when to fall back to local workflows.