The Old gh copilot Is Retired: Migrating to the New GitHub Copilot CLI

A gh copilot suggest replacement is what many developers are searching for, and you're probably running into the same confusion a lot of developers are seeing right now: the old gh copilot extension workflow is retired, and the new GitHub Copilot CLI is not a simple rename. The migration matters because the retired gh copilot suggest and gh copilot explain subcommands trained many of us to think in one-shot command helper terms, while the new copilot command is an agentic terminal session that can reason, inspect, execute, and iterate.

That shift is useful, but it can also be disorienting. If you expected a direct replacement for the retired gh copilot suggest subcommand, the new workflow may feel heavier at first. The better mental model is not "where did my old subcommand go?" It is "how do I ask the new agent for the same outcome safely?"

Heads up: GitHub Copilot CLI moves fast. It went GA in February 2026 and ships updates constantly, so commands, flags, and available models change often. Everything here was verified against the CLI as of July 2026 -- always check the official GitHub Copilot CLI docs for the very latest.

Why This gh copilot Suggest Replacement Search Is Confusing

The name collision is the root problem. For a while, "Copilot in the CLI" meant a now-retired GitHub CLI extension installed with gh extension install github/gh-copilot. That retired extension added two memorable commands: gh copilot suggest for generating shell commands and gh copilot explain for explaining a command.

GitHub now says the GitHub Copilot extension for GitHub CLI is retired and has been replaced by the new GitHub Copilot CLI. That retired-extension docs page is the source I would trust over older blog posts, tutorials, or snippets that still present gh copilot suggest as current.

The new tool is installed as GitHub Copilot CLI and launched with copilot. GitHub's GA changelog describes it as a terminal-native coding agent that plans, builds, reviews, remembers across sessions, and works without leaving the terminal. That is a bigger product surface than the old command helper.

So the migration is not just syntax. It is a workflow change. If your goal is "tell me what command to run," the new CLI can still help. But it does that through an interactive or programmatic prompt, not a dedicated suggest subcommand. That is the practical replacement for the retired gh copilot suggest subcommand to internalize.

If you want more background on terminal agents and SDK-based approaches, I wrote about a different path in Build an AI CLI Developer Tool with GitHub Copilot SDK in C#. That article is about building your own tool. This article is about migrating to GitHub's shipped CLI.

What the Old gh copilot Extension Did

The old extension lived inside the GitHub CLI ecosystem. You installed it and then used two common subcommands:

# Retired GitHub CLI extension setup, shown only for migration context.
gh extension install github/gh-copilot

# Retired old subcommands, not current GitHub Copilot CLI commands.
gh copilot suggest "find large files in this repo"
gh copilot explain "git reset --soft HEAD~1"

That was a nice mental model. One command suggested a shell command. Another command explained one. It was narrow, predictable, and easy to teach.

The tradeoff was that the old gh copilot extension was not a full agentic development environment. It was useful when your task fit into the shape of "suggest this command" or "explain this command." It was less useful when the real job required reading repository context, checking files, running tests, updating code, and iterating on the result.

This is where the new GitHub Copilot CLI vs gh copilot distinction matters. The old extension centered on command translation. The new CLI centers on a terminal agent session. That creates more capability, but it also means you should be more explicit about permissions, scope, and expected output.

For .NET developers, the closest analogy is the difference between a helper method and a workflow object. A helper method does one small thing. A workflow object can coordinate multiple steps, which means it needs better boundaries. The same thinking applies when you move from the retired gh copilot suggest subcommand to the current copilot command.

Official Retirement Check: gh copilot Is Retired

This is the part I would verify before changing docs, onboarding material, or team scripts. GitHub's official page titled "Using the GitHub CLI Copilot extension" now says it provides details about the replacement for the Copilot extension for GitHub CLI. The page then states: "The GitHub Copilot extension for GitHub CLI is retired. It has been replaced by the new GitHub Copilot CLI."

That language is direct. It is not a soft deprecation note. It is not a naming preference. The old extension is retired.

The follow-on install docs point to the new CLI. As of July 2026, GitHub documents npm, WinGet, Homebrew, the install script, and direct downloads as current install options. The common commands are:

# Current GitHub Copilot CLI install options documented by GitHub.
npm install -g @github/copilot
winget install GitHub.Copilot
brew install --cask copilot-cli
curl -fsSL https://gh.io/copilot-install | bash

For the npm path, GitHub lists Node.js 22 or later as a prerequisite.

The installed command is copilot, not gh copilot. On first launch, GitHub documents that you start an interactive session with copilot, trust the current folder if appropriate, and authenticate with /login or copilot login when needed.

If your team has README snippets that still say gh extension install github/gh-copilot, treat those as migration candidates. If your automation still shells out to gh copilot suggest, treat that as technical debt. A replacement for the retired gh copilot suggest subcommand is not another gh extension command. It is a prompt to the new copilot executable.

This is also why I would be careful with old search results. Many articles age poorly here. GitHub Copilot CLI has changed quickly, and older instructions may have been correct when written but wrong today. When in doubt, prefer GitHub's current docs and the npm package page.

Before and After: Migrating Old gh copilot Habits

The most helpful migration step is to map the outcome you wanted from the old command to the new prompt style. You are not looking for exact parity. You are preserving the use case.

This is the migration pattern I recommend: replace old subcommands with explicit prompts. Say whether Copilot should only explain, only suggest, or actually run something. That single sentence often matters more than the command shape.

For example, if you want a replacement for the retired gh copilot suggest subcommand for command generation or explanation, ask for the outcome and tell the agent not to execute anything:

# Current GitHub Copilot CLI programmatic prompts.
copilot -p "Suggest a PowerShell command to list the 20 largest files under this repo. Explain the flags. Do not run it."
copilot -p "Explain this command and identify any destructive behavior: git clean -xdf"

Those prompts preserve the old use cases without pretending the new CLI has the same interface. That is the honest GitHub Copilot CLI vs gh copilot migration story.

The New Mental Model: Agentic Session, Not Command Explainer

The new CLI can answer questions, write and debug code, interact with GitHub.com, and work iteratively from your terminal. GitHub's current docs describe two user interfaces: interactive and programmatic. The interactive interface starts with copilot. The programmatic interface uses -p or --prompt so the CLI completes one prompt and exits.

That matters because the old extension returned a bounded answer. The new CLI may reason about your repository, request permission to run tools, and continue across multiple steps. In the interactive experience, GitHub documents approval choices when Copilot wants to use a tool that could modify or execute files. You can allow the action once, allow that tool for the rest of the session, or reject it and steer the agent differently.

There are pros and cons here.

The upside is context. If you ask, "Why is this test failing?" the new CLI can inspect the repo, read files, and run a targeted command if you approve it. That is much more capable than a command explainer. It also fits broader agentic patterns I discuss in Getting Started with Microsoft Agent Framework in C#, where tool boundaries and workflow orchestration matter.

The downside is scope. A command explainer is safer by default because it mostly talks. An agent can do things. So your migration should include prompt discipline, not just install instructions. Ask for "do not run it" when you only want advice. Ask for "explain assumptions" when you need to verify the command. Use approval prompts deliberately.

That is not fearmongering. It is engineering hygiene. The new GitHub Copilot CLI can be more useful than gh copilot, but it deserves the same kind of boundaries you would put around any tool that can modify files or execute commands.

Practical Replacement Prompts for Retired gh copilot suggest

Here are practical prompt shapes you can use while migrating. These are intentionally small. This article is not a deep feature tutorial for the new CLI; it is the bridge from old habits to new ones.

For a simple shell suggestion or command explanation, use programmatic mode when you want a one-off answer:

# Current GitHub Copilot CLI programmatic prompts.
copilot -p "Suggest a Bash command to find files over 100 MB under the current directory. Explain each flag. Do not run it."
copilot -p "Explain `git reset --hard HEAD~1` for a developer who wants to undo one commit. Include what data could be lost."

For a repository-aware suggestion, start the interactive UI from the repo root:

# Start a current GitHub Copilot CLI interactive session.
copilot

Then ask something like: "Suggest the smallest test command for the project in this folder. Do not run it until I approve." That is a better replacement for the retired gh copilot suggest subcommand than asking for a generic command because the agent can use repository context.

For a migration check across a repo, you can ask Copilot to inspect documentation without changing files:

# Ask the current GitHub Copilot CLI to report migration findings without editing files.
copilot -p "Find references to the retired gh copilot extension in this repository. Report file paths and suggested wording only. Do not edit files."

That last example is where the new CLI starts to pull away from the old extension. The retired gh copilot suggest subcommand could help you produce a search command. The new Copilot CLI can be asked to perform the investigation, summarize findings, and wait before editing. If your team has strong repository instructions, tests, and review habits, that workflow can save meaningful time.

If you are evaluating agent behavior more formally, the ideas in Evaluating AI Agents with Microsoft.Extensions.AI.Evaluation in C# are relevant even when the product is a CLI. Define what good looks like. Measure outcomes. Do not treat fluent output as proof.

A Safe Migration Checklist for Teams

Start by replacing the installation path. New setup docs should point developers to npm install -g @github/copilot, winget install GitHub.Copilot, brew install --cask copilot-cli, or the official install script depending on platform. Avoid documenting gh extension install github/gh-copilot as current.

Next, update examples. Any internal docs that say gh copilot suggest should become prompts to copilot. Any docs that say gh copilot explain should become explanation prompts. Both mentions refer to retired subcommands now. I would include the phrase "Do not run it" in examples where the old behavior was informational. That makes the new prompt safer and clearer.

Then decide how your team wants to use interactive versus programmatic mode. Interactive mode is better for exploratory migration, command explanation, and small repository-aware questions. Programmatic mode with copilot -p is better when you want a bounded answer that can be copied into a script or documentation workflow.

Finally, add guardrails where the agent can act. If you are using Copilot CLI in a codebase, repository instructions matter. The same theme shows up in Advanced GitHub Copilot SDK in C#: Tools, Hooks, Multi-Model, Multi-Agent: tools amplify the agent, so tool boundaries need design.

A simple migration policy could look like this: use copilot -p for one-shot command suggestions, use interactive copilot for repository-aware questions, require explicit approval before running commands, and review every generated command before execution. That is not complicated. It is enough to avoid treating a retired command helper and a modern agent as if they were identical.

Common Migration Mistakes to Avoid

The first mistake is searching for a package that does not exist in the current flow. The package is @github/copilot on npm, and the command is copilot. Do not install an older package just because an old post ranks well.

The second mistake is assuming suggest and explain disappeared as capabilities. They disappeared as retired subcommands. The capabilities still exist through natural language prompts. That difference is subtle but important.

The third mistake is giving the new CLI too much authority while trying to reproduce old behavior. If all you wanted from the retired gh copilot explain subcommand was a paragraph explaining a command, do not approve shell execution. If all you wanted from the retired gh copilot suggest subcommand was a command to inspect manually, say "Do not run it." Keep the permission model aligned with the use case.

The fourth mistake is turning this migration into a broad terminal-agent bakeoff. That is a separate discussion. The useful question here is narrower: how do you replace retired gh copilot habits with the current GitHub Copilot CLI workflow? Tool comparisons can be valuable, but mixing them into migration docs creates noise for developers who just need to get unstuck.

If you are thinking more broadly about AI developer tooling, GitHub Copilot SDK for .NET: Complete Developer Guide is a better place to separate SDK concepts from CLI usage.

FAQ

Is gh copilot retired?

Yes. GitHub's official docs say the GitHub Copilot extension for GitHub CLI is retired and has been replaced by the new GitHub Copilot CLI. For current docs, use the copilot command documentation rather than older gh copilot tutorials.

What is a practical replacement for retired gh copilot suggest?

The practical replacement for the retired gh copilot suggest subcommand is to ask the new CLI directly: copilot -p "Suggest a command to do X. Explain the flags. Do not run it." For repository-aware tasks, start copilot inside the repo and ask interactively.

What replaced gh copilot explain?

There is no direct one-to-one explain subcommand in the new workflow. Ask the agent to explain the command instead, ideally with risk included: copilot -p "Explain this command and identify destructive behavior: ...".

Is GitHub Copilot CLI the same as the old GitHub CLI extension?

No. The old GitHub CLI extension was a narrower command helper under gh copilot. The new GitHub Copilot CLI is a standalone copilot command with interactive and programmatic modes, tool approvals, repository context, and agentic workflows.

Should I still install github/gh-copilot?

No, not for a new setup. GitHub's current install docs point to the new GitHub Copilot CLI install methods, including npm, WinGet, Homebrew, the install script, and direct downloads.

Can I still ask for shell commands with the new CLI?

Yes. The difference is prompt style. Instead of the retired gh copilot suggest subcommand, use copilot -p or an interactive session and ask for the command you need. Add "Do not run it" when you only want the suggestion.

When should I use interactive mode instead of copilot -p?

Use interactive mode when context matters, when you want to steer the answer, or when the task may require follow-up. Use copilot -p when you want a bounded one-shot response, such as a command explanation or migration wording for documentation.

Wrapping Up: Migrate the Workflow, Not Just the Command

The old gh copilot extension was useful because it made command suggestion and command explanation easy. But it is retired. The new GitHub Copilot CLI is the current path, and the right migration is to translate old habits into explicit prompts against the copilot command.

If you need a replacement for the retired gh copilot suggest subcommand, ask the new CLI for a command, require an explanation, and say whether it should run anything. If you need a replacement for the retired gh copilot explain subcommand, ask for the explanation directly and include the command in backticks. If you need repository-aware help, start an interactive copilot session from the repo root and use the agentic workflow intentionally.

That is the key shift. You are not swapping one subcommand for another. You are moving from a retired command helper to a terminal-native agent. Treat it that way, and the migration gets much easier.