GitHub published a set of Copilot changes on June 25 that are easy to read as separate product notes. Together, they show where Copilot is going: deeper into code review, project-management context, and enterprise control surfaces.
The sharpest change is inside Copilot code review. GitHub says the review system now uses file-exploration tools from the Copilot CLI and SDK, including grep, rg, glob, and view, instead of custom file tools. GitHub says that change, plus instruction tuning, reduced code-review costs by about 20% while maintaining the same review-quality standard in offline and online evaluation.
That is not only an efficiency note. It means Copilot’s review path is becoming closer to the same tool-using agent surface developers use in the terminal.
Review depth is becoming a managed setting
GitHub also added more visibility and control for teams using the Medium analysis depth public preview. Copilot code review now labels medium-depth runs in the pull request overview comment, and organizations can set a default review level for repositories that have not configured one.
The practical effect is clearer accountability. If an automated review missed something, a team can tell whether it came from a medium-depth run. If an organization wants a higher or lower default review posture across repositories, it can set that once and still allow repository-level overrides.
That matters because AI code review is not a magic gate. It is a managed risk-control layer. Review depth, review cost, and review signal quality all need to be visible enough for engineering leaders to tune them deliberately.
Plugin governance moves before tool execution
GitHub’s second June 25 item is about plugin control. Enterprises can now add strictKnownMarketplaces to enterprise-managed settings.json so Copilot in VS Code and the Copilot CLI only allows plugins from explicitly defined marketplaces.
That is a small setting with a large governance implication. As coding agents gain plugins, skills, and MCP-style tool connections, the risk is no longer only what the model says. It is what the toolchain is allowed to install and execute before a developer notices.
GitHub frames this as a way to enforce client governance before tool execution. That is the right layer. A policy that only reviews agent output is late; a policy that controls trusted plugin sources shapes the agent’s working environment.
Jira makes the workflow wider
The third update is GitHub Copilot for Jira reaching general availability. Since the March 2026 public preview, GitHub says it added model selection, Confluence context through MCP, custom agents, custom fields, space-level guidance, and review-request notifications in Jira.
The GA release continues that direction with more visibility and control over agent sessions. For teams that live between Jira tickets, pull requests, and documentation, this is the important shift: Copilot is not confined to the editor. It is being placed across the planning-to-code path.
That can save context-switching, but it also creates new admin questions. Which Jira spaces can inform the agent? Which repositories can it touch? Which plugin marketplaces are trusted? Which review depth is the default? Copilot is becoming a workflow system, so it inherits workflow governance.
The enterprise question is auditability
The June 25 bundle is not a model launch. It is more useful than that for enterprise teams. GitHub is exposing the knobs that make AI coding systems governable: review depth, plugin allowlists, Jira context, tool behavior, and cost efficiency.
The next checkpoint is auditability. Teams will want to know which tool paths a review used, which Jira or Confluence context shaped an agent session, which plugins were available, and how much each workflow cost.
GitHub is giving Copilot more places to act. The operational burden is making those actions inspectable enough that teams can trust them in real software delivery.
