Guide · GitHub Copilot App · Preview
⚗ Technical Preview Power Platform ≈ reading…

GitHub Copilot App Setup Guide

GitHub's new native desktop app brings agentic coding out of the editor — sessions that start from issues and pull requests, run in isolated branches, and can merge themselves once checks pass. It's early, but it points at where AI-assisted development is heading.
In this guide
This is a technical preview. GitHub announced the Copilot App on May 14, 2026. Access is rolling out gradually, features are changing fast, and the exact screens may differ from what's described here. Treat this as an orientation, not a frozen reference — and check the official changelog for the latest. Don't run preview tooling against production environments.
  • Early access to the GitHub Copilot App (Pro/Pro+, or via your org admin)
  • The app installed and signed in to your GitHub account
  • Your first agentic session, started from a GitHub issue or pull request
  • An understanding of Agent Merge — and where to keep a human in the loop for Power Platform work

What Is the GitHub Copilot App?

The GitHub Copilot App is a GitHub-native desktop application built for agentic development. Instead of living inside your editor like Copilot in VS Code, it's a standalone app where Copilot does multi-step work in focused sessions and you supervise.

The core ideas:

  • Start from GitHub context. Kick off a session straight from an issue, a pull request, a prompt, or a previous session — with the issue details and repo state already connected.
  • Focused, isolated sessions. Each session has its own branch, files, conversation, and task state. You can pause one and resume it later without it bleeding into another.
  • Steer and validate. Review the plan and the diffs, run terminal commands, open a browser preview, and test changes before a pull request is created.
  • Agent Merge. The agent can address review comments, fix failing checks, and merge once the conditions you set are met.

How It Differs From What You Already Know

ToolWhere it livesBest at
Copilot in VS CodeInside your editorInline completions and chat while you write code
Claude Code (desktop/CLI)Desktop app or terminalGenerating whole solutions, running PAC CLI, managing git
GitHub Copilot AppStandalone GitHub-native desktop appAgentic sessions that start from GitHub work items and can self-merge

If Copilot-in-VS-Code is "help me as I type" and Claude Code is "build this for me," the Copilot App is "take this issue and drive it to a merged PR, while I supervise."

Before You Start

PrerequisiteWhyGet it
A Copilot subscriptionPro/Pro+ can sign up for early access as the preview expands. Business/Enterprise access rolls out via your org.github.com/features/copilot/plans
Preview access enabledFor Business/Enterprise, an admin must enable previews and have Copilot CLI enabled in policy settings.Ask your GitHub org admin
A GitHub repo for your projectThe app works from GitHub context — issues, PRs, branches. Your Power Platform solution should already be a repo (see the GitHub Desktop guide).GitHub Desktop guide

1. Get Access

Because this is a preview, you don't just download it — you opt in first.

  • Pro / Pro+: sign up for early access from the preview announcement. Access expands gradually, so you may join a queue.
  • Business / Enterprise: access rolls out through your organisation. An admin needs to enable previews and ensure Copilot CLI is enabled in policy settings before it appears for you.

Preview availability changes week to week. If you don't see it yet, that's expected — check the changelog for current rollout status rather than assuming something's broken.

2. Install and Sign In

Once access is granted, install the app from the location GitHub provides for your account or organisation, launch it, and sign in with your GitHub account. The first-run flow walks through connecting your repositories.

Exact install steps and screens are still moving during the preview. Follow the in-app onboarding and the official docs linked from the changelog — that's the source of truth while this stabilises.

3. Start Your First Session

The defining move of the Copilot App is starting from GitHub context rather than a blank prompt.

  1. Pick a starting point: a GitHub issue, a pull request, a prompt, or a previous session.
  2. The app opens a focused session with an isolated branch and the connected context loaded.
  3. Copilot proposes a plan. Read it before letting it run — this is your first checkpoint.

For Power Platform, a natural first session is something like: an issue titled "Notify technician flow throws on portal-created work orders", with your solution repo connected. The agent reads the issue, the flow JSON, and the repo history, then proposes a fix on its own branch.

4. Steer and Validate

This is where your judgment does the work. Before any pull request is created, you can:

  • Review the plan and the diffs — see exactly what the agent intends to change.
  • Run terminal commands — e.g. pac solution check, or your flow tests, right inside the session.
  • Open a browser preview — useful for Power Pages sites or Code Apps.
  • Test the change before it leaves the branch.

Reject what's wrong, steer with a follow-up message, and only let it open the PR when the diff is right.

5. Agent Merge — and Where to Stop It

Agent Merge lets the app address review comments, fix failing checks, and merge automatically once your conditions are met. Powerful — and exactly the kind of thing to scope carefully on Power Platform projects.

Recommended guardrails for Power Platform: let the agent open and iterate on PRs against a dev branch, but keep a human approval on the merge to main. Never let preview tooling auto-merge changes that flow into a managed-solution promotion toward UAT or Production. Schema changes, connector edits, and anything touching a managed environment stay human-approved.

How It Fits Your Power Platform Workflow

The Copilot App slots into the same ALM loop the book describes: an issue or failing check kicks off a session, the agent diagnoses and proposes a fix on a branch, you review the diff and run pac solution check, and a pull request carries it to your review gate. The difference is that more of the loop runs inside one supervised app — which is promising, but in preview it's a place to experiment in dev, not to wire into your production pipeline yet.

  • It's a technical preview. Features and screens are changing; treat this as orientation and keep it in dev environments.
  • GitHub-native, agentic, session-based. Sessions start from issues/PRs, run on isolated branches, and you supervise.
  • Access is opt-in. Pro/Pro+ sign up for early access; Business/Enterprise get it via admin policy.
  • Steer before the PR. Review plans and diffs, run pac solution check, test — then let it open the pull request.
  • Scope Agent Merge carefully. Fine to iterate on dev; keep human approval on merges that head toward managed environments.

Where to Next