Weekly GitHub Copilot Roundup: Agents, Hooks, and Safer Autonomy

by TechHub

This week’s Copilot updates continued the move toward agentic workflows: more autonomy in editors and the CLI, more customization through instruction files and hooks, and more attention on running agents safely in real repositories. Building on last week’s VS Code lifecycle hooks, default memory, and MCP tool integrations, these ideas are now showing up across IDEs (notably JetBrains) with more reviewable on-disk configuration plus better observability, troubleshooting, and governance. Copilot also kept improving everyday workflows, including faster terminal-based code review requests, better web repo exploration, and portfolio-scale modernization that ties code changes to migration planning.

Agentic Copilot in IDEs: customization, autonomy, and observability

GitHub Copilot’s JetBrains plugin moved key in-IDE agent building blocks to GA - Custom Agents, Sub-agents, and a Plan Agent - so teams can define specialized roles inside IntelliJ workflows. This matches last week’s “configurable teammate” theme from VS Code and helps teams using multiple IDEs get more consistent behavior. Customization is also shifting toward files: Copilot can discover AGENTS.md and CLAUDE.md in the workspace (or apply them globally), and a new /memory command jumps to settings for those instruction sources. With Copilot Memory now default for Pro/Pro+, the direction is clear: manage agent behavior with explicit, reviewable instruction artifacts instead of relying on transient chat context. In preview, JetBrains adds Agent Hooks to run automation at lifecycle events (userPromptSubmitted, preToolUse, postToolUse, errorOccurred) via .github/hooks/hooks.json, enabling policy checks and integrations during agent execution. This continues last week’s VS Code lifecycle-hook work (auto-linting, output restrictions, safer automation) and brings similar tool-usage hook points to JetBrains in a repo-visible way. For MCP tool usage, Auto-Approve for MCP reduces repeated confirmations by letting you set auto-approval per MCP server/tool in JetBrains settings, but teams should treat it as a policy choice, especially given last week’s emphasis on terminal sandboxing and safety constraints. JetBrains also has Auto Model Selection GA across all plans. Copilot can route completions among models (including GPT‑5.4, GPT‑5.3‑Codex, Sonnet 4.6, Haiku 4.5) based on availability/performance while respecting entitlements and admin policies, and it shows which model responded. This connects to last week’s model-management thread (explicit model selection for @copilot in PR comments, plus deprecations/migrations) by adding policy-bounded routing with transparency. Billing adds a detail: auto-routed requests get a 10% discount on the model’s premium multiplier (and currently routes only to 0x–1x multiplier models). VS Code’s Copilot surface area evolved in parallel. Insiders 1.111 aligns instruction handling by recursively discovering *.instructions.md under .github/instructions/, which reduces “why was my instruction ignored?” differences across CLI, agents, and editor. This extends last week’s “shared memory/context” theme toward a clearer repository convention. Customization is also easier to debug and more modular: custom agent frontmatter supports agent-scoped chat hooks, and /troubleshoot helps inspect hook/customization behavior from chat. After last week’s conversation forking, live steering, and memory controls, the emphasis this week is diagnosing how hooks, instructions, and tool policies interact. Insiders also added OpenTelemetry instrumentation for Copilot Chat (subject to telemetry settings), giving teams traces to diagnose latency, failures, or regressions during controlled rollouts. This complements last week’s enterprise management angle (session filtering, network routing, usage metrics) by expanding visibility from “what users did” to “what happened in the agent loop, and why.” VS Code 1.111 (and discussion of the weekly stable cadence) also put more focus on autonomy modes: default approvals, bypass approvals, and an autopilot mode where Copilot continues end-to-end with auto-approved tool calls and retries. This builds on last week’s autonomy trend (more capable agents, terminal sandboxing, output restrictions) while making trade-offs more explicit: fewer interruptions for multi-step tasks, but a different security posture on developer machines. The same release also expanded hook control (scoping hooks to custom agents behind chat.useCustomAgentHooks) and improved debugging with “debug events snapshot” attachments you can carry into a new chat (including references like #debugEventsSnapshot) to diagnose issues such as unsupported model config values.

GitHub Copilot CLI and PR workflows: multi-agent parallelism and terminal-first review

Copilot’s terminal workflows kept reducing the “do it without leaving the shell” gaps. After last week’s Copilot CLI GA push (plus tutorials, metrics, dashboards), this week connects terminal work more directly to PR review, including a faster way to request agentic review. GitHub CLI v2.88.0 can request Copilot Code Review from the command line by adding Copilot as a reviewer (gh pr edit --add-reviewer @copilot) or selecting it during interactive PR creation. With last week’s focus on Copilot Code Review’s agent architecture and scale, this is a simple way to trigger the same review automation without switching to the web UI. In the same release, reviewer/assignee selection moved to search-as-you-type instead of preloading large collaborator lists, which improves performance in large orgs and improves accessibility (screen readers avoid massive lists). It also supports the enterprise adoption theme from last week: as Copilot expands, supporting tooling is adjusting to large repositories and workflows. On the Copilot CLI side, the new /fleet command goes beyond single-agent help by running multiple Copilot-powered tasks in parallel from one prompt, targeting maintenance work like dependency upgrades, documentation updates, and batching issues. This builds on last week’s “agent workflows beyond the IDE” direction (CLI automation, repo bots, MCP servers) by moving from sequential help to parallel orchestration, then returning combined output for review before merging. For onboarding, beginner tutorials covered setup (npm install, auth, folder permissions) and two prompting styles: interactive mode for iterative sessions versus non-interactive -p for quick one-offs. This continues last week’s hands-on learning angle and reinforces that terminal workflows are a first-class Copilot surface, not just an IDE add-on.

Modernization agents and migration integration: from repo changes to portfolio orchestration

Modernization came up repeatedly, with Copilot positioned less as “write code” and more as “upgrade estates.” This fits the progression from last week’s agentic repo automation and enterprise controls (session filtering, routing changes, user metrics): as Copilot automates across many repositories, teams need plans, governance, and standardized skills. GitHub Copilot’s modernization agent entered Public Preview with a portfolio workflow: run assessments, generate plans, and convert output into GitHub Issues and PRs so work stays in normal review/CI. It also emphasizes cross-repo coordination (async execution), centralized monitoring/governance via Agent HQ, and custom skills to enforce org rules across upgrades, especially for .NET and Java. Microsoft also introduced modernize-dotnet, a Copilot coding agent with an “Assess → Plan → Execute” flow callable from Visual Studio (Solution Explorer), VS Code (modernization extension), Copilot CLI (marketplace plugin), and directly in GitHub repos. This continues last week’s “Copilot across surfaces” thread (IDE + web + CLI + MCP), but applied to long-running, review-heavy work. The focus is on producing structured, versionable artifacts (assessment and plan) alongside code changes so teams can review intent, not only diffs. It covers many workloads (ASP.NET Core, Blazor, Azure Functions, WPF, libraries, console apps) and supports .NET Framework migrations (Windows required). At the program level, Azure Copilot’s Migration Agent and GitHub Copilot are described as complementary. Azure Copilot handles discovery/assessment (including agentless VMware discovery and offline inventory via Azure Migrate Collector), produces 6R recommendations, wave plans, and landing-zone setup aligned to the Cloud Adoption Framework, then links developer modernization work via GitHub Copilot integration. The shared theme is tighter coupling between “what to modernize/migrate” and “make code/config changes,” reducing silos between infrastructure planning and repo work. It also extends last week’s point that agents are becoming workflow participants that need traceability and controls.

Security, governance, and “auto-approval” controls for agentic workflows

As Copilot shifts toward autonomy (auto-approve, autopilot, multi-agent execution), security guidance is becoming more specific. This follows last week’s lifecycle hooks, terminal sandboxing, output restrictions, enterprise session filters, and outbound routing changes: as agents gain permissions, teams need consistent guardrails across IDEs, Actions, and the CLI. GitHub’s deep dive on “GitHub Agentic Workflows” security (agents via GitHub Actions) describes a defense-in-depth model that treats the agent as untrusted and designs for prompt injection, privilege escalation, secret exfiltration, and unsafe repo changes. It uses isolation (Actions runner VMs, hardened containers), declarative permission scoping, firewalled egress, and “zero secrets for agents” (secrets outside agent runtime in isolated proxies/containers). Repository writes go through a “safe outputs” pipeline so changes can be buffered and vetted before applying, backed by policy controls (limits on PR/issue creation, moderation/sanitization) and logging/observability for audit and incident response. GitHub also added a repository-level Actions control: admins can optionally skip the “Approve and run workflows” gate for workflows triggered by the Copilot coding agent. That speeds CI while Copilot iterates on PRs, but it moves the speed/safety tradeoff onto workflow hardening (token permissions, secret exposure, environment protections, and exfiltration risk under malicious inputs). It lines up with this week’s autonomy levers in IDEs (JetBrains MCP auto-approve, VS Code autopilot/bypass approvals) with an equivalent CI-side switch. It can work well when hardening is in place, and it can be risky when it is not.

Other GitHub Copilot News

Copilot’s web experience added a repository-exploration preview that brings file tree browsing into Copilot Chat on GitHub.com. You can ask Copilot to open files, navigate the tree, and attach files as temporary references. To keep context, you can pin a file by converting it into a permanent reference from chat tokens or the file preview. This matches last week’s push for persistent context (Copilot Memory default-on) and faster repo exploration in IDE agents, and it gives the web UI more explicit, user-controlled context attachment and retention.