Copilot CLI 1.0.64 Promotes MCP and Security Review From Experimental Toys to Daily Workflow Surfaces
GitHub Copilot CLI shipped version 1.0.64-0 this morning, and the headline is not any single feature — it is the pattern those features form when you look at them together. MCP registry installation, /security-review without an experimental flag, /diagnose for session-log analysis, CSV output for MCP tools, and /loop as a named alias for scheduled commands. On the surface, that sounds like a random collection of additions. Step back, and it is clearly a statement about what GitHub thinks a metered coding agent needs before it can be trusted with real work: installability, diagnostics, security review, and budget-aware looping.
The MCP registry addition is the most strategically significant. MCP has moved from "interesting protocol that developers paste into config files" to the actual control surface for agent tools. When Copilot CLI can browse and install MCP servers from inside the terminal, GitHub is reducing the setup friction that keeps most teams from wiring Copilot into their issue trackers, documentation systems, databases, cloud tools, and internal services. That is genuinely useful. It is also a meaningful expansion of the tool's potential blast radius. Every MCP server that gets installed is a new trust boundary. The registry makes that easier; it does not make it safer.
Making /security-review available to all users without the --experimental flag is the other significant signal in this release. Security review is exactly the kind of agent task that feels impressive in a demo and messy in production. The agent needs repository context, diff context, dependency context, sometimes secret-scanning context, and a clear line between "flag risk" and "make changes." Promoting the command out of experimental mode suggests GitHub thinks the workflow is mature enough for broader use. That may be true. Teams should still treat it as a first-pass reviewer aid, not a replacement for code review, static analysis, or a dedicated security program. The useful pattern is: run security review, inspect the evidence, convert findings into tests or code changes, then let CI and human reviewers close the loop. The agent can do the fast扫描. Humans still need to do the thinking.
/diagnose is the release's most underrated addition, and it is underrated precisely because it is boring. Coding agents fail across many layers: model output, tool calls, MCP server startup, authentication, content exclusion rules, streaming, quota limits, shell execution, editor integration, and remote state. When a session loops or produces bad output, developers need a way to determine which layer failed. A command that analyzes session logs gives teams a path to debug the harness instead of blaming the model — or, more often, instead of burning another premium request on a session that is going to fail the same way. In a metered environment where every agent loop has a real cost, diagnostics are not a nice-to-have. They are how users avoid paying twice for the same mistake.
The image persistence fix deserves specific attention because multimodal coding is no longer a fringe workflow. Screenshots of UI bugs, generated diagrams, canvas snapshots, browser states, and tool-returned images are increasingly normal inputs to coding agents. If images disappear from model context after a resume — vanishing from later turns even though they were part of the original thread — the agent may continue confidently with incomplete evidence. That looks like bad reasoning. The root cause is state loss. Keeping tool-returned images visible across later turns and resumed sessions is basic continuity for any developer working on UI-heavy code, and it is the kind of fix that prevents a whole class of "the model ignored what I showed it" complaints.
The release also fixes friendlier messaging when usage limits are reached, which sounds trivial until you have watched a developer burn through credits trying to understand why their agent session suddenly stopped responding. In a subscription product, a limit message is a UI polish issue. In a metered product, it is a budget control. Users need to understand what is consuming their allocation before they start the large refactor, not after they have already burned through half their monthly credits on exploratory prompts.
For teams adopting this prerelease, the test plan is straightforward. Install an MCP server through /mcp and confirm the provenance and permissions of what you just added to your agent's tool surface. Run /security-review on a small pull request and inspect whether the findings include actionable evidence or just noise. Trigger /diagnose on a deliberately broken session so your team knows what good diagnostics output looks like. Verify that Azure CLI, PowerShell, and Developer CLI credential paths work correctly if your team uses Azure authentication. And because this is a prerelease, keep 1.0.63 as the default for critical work until these surfaces prove themselves in daily use.
The repo had 10,811 stars and 1,719 open issues at research time. That is meaningful scale for a CLI tool that most developers still do not think about as their primary agent interface. The gap between "interesting terminal experiment" and "trusted daily driver" is exactly the kind of reliability and governance work this release is doing. GitHub is building the affordances a metered coding agent needs before teams can hand it more than toy edits. Whether that construction is fast enough to stay ahead of Anthropic's Claude Code, OpenAI's Codex, and the growing field of terminal-native agents is the competitive question that will play out over the next several releases.
Sources: GitHub — github/copilot-cli v1.0.64-0, github/copilot-cli repository, GitHub Docs — Models and pricing for Copilot