GitHub Copilot CLI is now generally available with tabs, inline MCP setup, and in-terminal settings, and honestly, that is more important than it sounds. The headline feature is UI polish, but the practical shift is that GitHub is making terminal-native agent workflows much easier to adopt without asking engineers to hand-edit config files.
That matters because the old friction was real. If you want people to actually use MCP servers, skills, and plugins, /mcp add, /plugin, /skills, and /settings inside the session is the right move. I like this. It lowers setup time and removes a lot of avoidable yak-shaving.
What is new in Copilot CLI?
The GA interface adds a tabbed terminal layout. In an interactive copilot session, you can switch between a default Session tab and a Gists tab. If you run it inside a GitHub repository, you also get Issues and Pull requests tabs for that repo.
That means you can stay in the terminal, highlight an issue or PR, press c to drop a reference into your prompt, and ask Copilot to investigate, fix, comment on, or review it. You can press o to open the selected item in the browser, and / to search issues or pull requests.
For setup and customization, GitHub also moved more admin work into the terminal itself:
/mcp add
/mcp search
/skills
/plugin
/settings
/theme
This is the part I think engineers will use most. Guided configuration is simply better than telling every dev to go edit JSON by hand, even if hand-editing still has its place for repeatable team setups and custom MCP servers.
Why this is good in practice
The main win is context flow. If you live in terminal-heavy workflows, jumping out to the browser or a config file is exactly the kind of friction that kills adoption. Tabs for issues and pull requests are not flashy, but they are useful.
It also lines up with where GitHub Copilot CLI is going more broadly: visible approval steps, MCP-powered tools, and more agent-like behavior in the terminal. Microsoft documentation already positions Copilot CLI as the terminal mode when you want direct control, and that is the right framing. For many engineering teams, this will fit beside editor-based agents, not replace them.
There is also a decent accessibility story here: theme-aware colors, high-contrast and colorblind modes, responsive layouts for narrow terminals, and screen reader support that auto-enables when detected. Good. Terminal tools usually treat accessibility as an afterthought.
What I would watch: permissions, plugins, and spend
This is where the shiny UX can hide the real risks.
First, an agent should not get a blank check to your tenant, repo estate, or local machine. Making MCP servers and plugins easier to install is good for usability, but it also increases the chance that teams enable tools faster than they review them. If you connect Copilot CLI to Azure, Dataverse, Microsoft 365, or internal systems, least privilege matters even more than convenience. If you need help putting controls around that, this is exactly the kind of thing I would review in an AI and automation audit.
Second, billing is getting more granular across GitHub and Microsoft AI tooling. Community research around this release points to per-request billing transparency, which is good, but transparent billing is not the same as cheap billing. Microsoft documentation for GitHub AI-related features in Azure DevOps says 1 credit equals $0.01 USD. Different features consume different amounts, and costs vary by task size and model use. That is the part finance teams usually discover late.
What this means in practice: once developers can easily wire in tools and start agentic flows, usage tends to spread faster than governance. Then cost follows. Then someone asks why a terminal helper is now touching Azure subscriptions and external MCP registries. For teams building broader Copilot and AI agents, this is not just a UX update. It is an operational control question.
My take
This is a good release. It fixes real usability problems and makes Copilot CLI feel like a product teams might actually standardize on.
But I would not confuse easier setup with solved governance. The better GitHub gets at making terminal agents feel natural, the more you need clear guardrails on what tools can be installed, what identities they run under, and who owns the bill.
If you already use terminal-first automation, update with copilot update and test it. Just do the boring admin work too: review installed plugins, review MCP scope, and make sure somebody is watching usage before it turns into another metered surprise.
