GitHub Copilot App: What It Does and Where It Fits

The GitHub Copilot app is a desktop application for macOS, Windows and Linux where you direct Copilot agents instead of typing code yourself. You pick a repository, start a session, choose how much freedom the agent gets, and it works on its own branch in its own Git worktree; several sessions can run at once. Your issues, pull requests, reviews and CI results sit in the same window, so you can go from an issue to a merged pull request without switching to a browser. It is built on Copilot CLI, it is not a code editor, and as of September 30, 2026 it is available on every Copilot plan, or with your own model provider’s key.

Which “Copilot app” this is

The phrase gets used for several things, so it is worth being precise. This post is about the desktop app GitHub calls the GitHub Copilot app, which became generally available on June 17, 2026. It is not:

• GitHub Mobile, the phone app, where Copilot Chat answers questions about a repository, a file or a pull request.
• GitHub Desktop, the older Git client, whose Copilot features are commit message generation and help resolving merge conflicts.
• Microsoft Copilot, the general-purpose assistant, which is a separate product from GitHub Copilot.
• Copilot in VS Code or another editor, which is an extension inside the editor rather than an app of its own.

What it does

GitHub’s overview of the GitHub Copilot app↗ (opens in a new tab) calls it a desktop application purpose-built for agent-driven development. In practice that comes down to a handful of things:

• Parallel sessions: run several agent sessions at the same time, each with a dedicated Git worktree and branch, so two tasks never edit the same files.
• GitHub built in: repositories, branches, issues and pull requests are part of the app, not a link out to the website.
• A review loop: inspect the diff, check the result in a terminal or browser, and open a pull request using your team’s existing workflow.
• Automations: save a recurring agent task and run it on a schedule, on demand or when something happens in a repository.
• Canvases: agent-driven artifacts and interfaces that people and agents can work on together.
• Customization: global and per-repository instructions, MCP servers, agent skills and custom agents.

Sessions: where they run and how much freedom they get

Every piece of work is a session. According to GitHub’s page on working with agent sessions↗ (opens in a new tab), you start one from the plus icon next to Projects, choose a project (a folder already on your machine, a repository from GitHub, or a Git URL), then pick where it runs:

• A new working tree: an isolated workspace on your machine, the safest default for parallel work.
• Your local repository: the checkout you already have, optionally with local sandboxing, which limits what agent-run tools can reach on your files, network and credentials. Local sandboxing is in public preview and off by default.
• A cloud sandbox: the whole session runs in an isolated environment hosted by GitHub.

Then you pick a mode. Interactive means you and the agent work together and it waits for your input before proceeding. Plan means it writes a plan first and executes only after you approve it. Autopilot means it writes code, runs tests and iterates without waiting for you. You also choose a model and a reasoning effort for each session; Auto lets the app pick a model based on how complex the task looks. Slash commands such as /security-review and /sandbox are available in the prompt box.

A sensible habit for a first week: new working tree, Plan mode, and the model you already trust elsewhere. Move to Autopilot only for tasks whose result you can check with a diff and a test run.

Issues and pull requests in the same window

The part that sets the app apart from an editor is the GitHub side. GitHub’s page on managing issues and pull requests↗ (opens in a new tab) in the app describes the loop:

1. My Work in the sidebar lists your issues and pull requests, split into All, Active, Review requests and Done, with search.
2. Open an issue and choose New session. Plan or Interactive is a good choice here, so you see the approach before any code.
3. When you ask the agent to open an issue or a pull request, it follows the repository’s issue and pull request templates.
4. Review the diff in Files changed. Ask the agent to make changes, or leave review comments yourself.
5. Next to a review comment or a failing CI check, the Copilot icon asks the agent to deal with it.
6. Agent merge lets the session fix what is blocking the pull request and merge it as soon as GitHub allows. Your branch protections and required checks still decide what “allows” means.

Automations build on the same loop. A local automation runs from your machine; a cloud automation can run while your computer is off. Triggers include manual, hourly, daily or weekly, a custom CRON expression (local only) and repository events such as a new issue.

Signing in, and which plans include it

GitHub’s quickstart for the Copilot app↗ (opens in a new tab) lists three prerequisites: a GitHub account, either a Copilot plan or credentials for your own model provider, and Git installed locally. Download the app for your platform, open it and choose Sign in to GitHub, or Use GitHub Enterprise if your company is on it. You then choose between a Copilot plan and your own model provider, pick repositories from your recent activity (or skip that), and you are ready for a first session.

• Plans: the July 7, 2026 changelog↗ (opens in a new tab) opened the app to every Copilot plan, including Copilot Free and GitHub Education. GitHub’s individual plans are Copilot Free, Copilot Student, Copilot Pro, Copilot Pro+ and Copilot Max; for companies, Copilot Business and Copilot Enterprise. Check GitHub’s plans page for what each includes.
• Your own key: without any Copilot plan, you can use a provider such as OpenAI, Azure OpenAI, Anthropic, Ollama, LM Studio or any OpenAI-compatible endpoint. With a plan, you can use both.
• Business and Enterprise: an admin policy has to allow it. GitHub’s pages word this differently: the app docs say the GitHub Copilot app policy must remain enabled (it is on by default), while the June and July changelog entries say the admin must have Copilot CLI enabled in policy settings. If the app will not start for you at work, ask about both. For those plans the app also respects content exclusions set at enterprise, organization and repository level.

How it relates to VS Code, the CLI and the cloud agent

GitHub now has four places where a Copilot agent can do the work, and the app overlaps with each:

• Copilot CLI: the app is built on it. MCP servers and agent skills you configured for the CLI are automatically available in the app, so a server added once works in both. Use the CLI when you want one agent in a terminal, over SSH or in a script; setup is in GitHub Copilot CLI.
• VS Code: an editor with Copilot inside it. You read and change code line by line and the agent works in the file you have open. The app is the other way around: you manage sessions and review their diffs, and open an editor when you want to work on the code yourself.
• The cloud agent (formerly the coding agent): you assign an issue on GitHub.com and it works on GitHub Actions and returns a pull request. The app’s cloud sandbox also runs a session away from your machine, but GitHub’s app pages describe it as a sandbox for an app session and do not equate it with the cloud agent. How the cloud agent works is in the GitHub Copilot coding agent.
• GitHub Mobile: for questions and following along away from your desk, not for running sessions.

A rough rule: the editor for work you want to watch line by line, the CLI for one agent in a terminal, the cloud agent for an issue you want back as a pull request, and the app when you are running several agents at once and spending your time reviewing rather than typing. If you are weighing Copilot against another editor-centered tool, see what Cursor AI is.

Customizing it

GitHub’s page on customizing the Copilot app↗ (opens in a new tab) describes two levels of instructions, both set in the app’s settings: App instructions, which apply to every session in every project, and repository-specific instructions under Projects. Custom agents are picked from the agent menu or with /agent. Skills and MCP servers configured for your repositories or for Copilot CLI appear in the app without extra setup. The page does not list which instruction files in the repository the app reads, so keep your repository’s AGENTS.md or .github/copilot-instructions.md for the other Copilot surfaces and put app-wide preferences in App instructions. What to write in those files is in copilot-instructions.md examples.

One board across all those sessions

Parallel sessions are the app’s strength and also the problem: four branches, four conversations, and the plan behind them in your head. fenbs keeps that plan outside any one session. Each task has a note saying what and why, a plan, and a test status with notes, in lanes To Do, Next Up, In Progress and Completed, and History records which assistant changed what. Because the app picks up MCP servers configured for Copilot CLI, one command connects both:

copilot mcp add --transport http fenbs https://fenbs.ai/api/mcp

Sign in with OAuth when asked, or issue a token under Settings with a name, scopes and an optional expiry; revoking it ends access. Then add one line to App instructions: “Start each session by reading its task with fenbs_get_item; when you open the pull request, comment on the task with the link and set its test status to what you actually ran.” Leave the move to Completed to a person after the merge. fenbs is deliberately small: it has no sprints, due dates or epics, and you cannot set an assignee.