How to Use the GitHub Copilot App: Setup, Projects, Automations and Computer Use (2026 Guide)

The GitHub Copilot app is a free-to-download desktop app (macOS, Windows, Linux) where you tell AI agents what to do and review what they hand back, instead of typing code yourself. Any Copilot plan works, including Copilot Free and Copilot Student, and you can even use it without a plan by plugging in your own model provider’s API key. At GitHub Universe on October 28, 2026, GitHub added Projects (give Copilot a goal and let it coordinate several agents), connected-tool context from apps like Slack and Figma, image generation, and computer use (Copilot can click through your desktop apps). This guide walks through every screen you need, which options to pick, what each choice costs, and the mistakes worth avoiding. Every fact below was checked against GitHub’s official documentation, changelog and release notes on October 29, 2026.

Key facts (from GitHub Docs, the Universe changelog and the github/app releases):

  • Who can use it: all Copilot plans (Free, Student, Pro, Pro+, Max, Business, Enterprise). No plan? Use bring-your-own-key (BYOK) with your own model provider.
  • Platforms: macOS, Windows and Linux. On Windows it can also run sessions inside WSL 2.
  • Current version: v1.1.33 (released October 27, 2026). The app auto-updates.
  • Cost: the app is free; agent work is billed in GitHub AI Credits (1 credit = $0.01). Cloud sandboxes have their own small usage meters.
  • Preview features: Projects, computer use and BYOK are in public preview and may change.
  • Not supported: GitHub Enterprise Server.

What the app is (and how it differs from Copilot in your editor)

Most people met Copilot as autocomplete inside VS Code. The Copilot app is a different thing. GitHub describes it as “a desktop application purpose-built for agent-driven development”. You don’t edit files in it the way you would in an editor. You hand tasks to agents, watch their progress, answer their questions, look at the changes they made, and merge the result.

Under the hood the app is built on GitHub Copilot CLI, so anything the CLI can do the app can also do, but with buttons, lists and previews instead of a terminal. Three ideas make it different from a chat window:

  • Parallel sessions. Each local session runs in its own isolated git worktree (a separate working copy on its own branch). You can have one agent fixing a bug, another updating documentation and a third answering a question about the codebase, and they don’t overwrite each other’s files.
  • Cloud sessions. You can run a session in a GitHub-hosted cloud sandbox instead of on your computer. Because it runs in the cloud, you can start it in the app, check on it from GitHub Mobile, and pick it back up on github.com or in VS Code.
  • The whole pull request lifecycle in one place. Browse issues, start a session from an issue, open a pull request, read CI results, leave a review and merge, all without opening a browser tab.

If you’ve used Claude Code in the cloud or Replit’s cloud agents, the idea will feel familiar. The difference is that the Copilot app lives directly on top of GitHub, so your repositories, issues, branches and checks are there without any extra connection step.

Before you start: what you need

From the official quickstart:

  1. A GitHub account. You must sign in with GitHub even if you use your own model provider.
  2. A Copilot plan, or your own model provider. Any plan works. If you go the BYOK route, have an API key from your provider ready.
  3. Git installed on your computer. The app uses Git to create branches and worktrees. If you’ve never installed it, follow GitHub’s Install Git guide first. This is the one technical prerequisite and the most common reason a first session fails.

At work? If your Copilot seat comes from Copilot Business or Copilot Enterprise, your administrator controls a separate “GitHub Copilot app” policy. It is on by default and is separate from the Copilot CLI policy, so if the app says you don’t have access while the CLI works, ask your admin to check that specific policy. Cloud sessions and cloud automations also depend on the “Copilot cloud agent” policy being enabled.

Step 1: Install the app

The download links are on the github/app repository page:

  • Mac: separate downloads for Apple Silicon and Intel. If you use Homebrew, the cask is called github-copilot-app.
  • Windows: installers for x64 and ARM.
  • Linux: an AppImage (.deb packages are also on the Releases page).

Pick the build that matches your machine (on a Mac, About This Mac shows whether you have Apple Silicon). The app updates itself.

Step 2: Sign in and finish onboarding

  1. Open the app and click Sign in to GitHub, then follow the browser prompts.
    • If your company uses GitHub Enterprise Cloud with data residency, choose Use GitHub Enterprise and enter your *.ghe.com hostname.
    • GitHub Enterprise Server is not supported, so self-hosted GitHub installs can’t use the app.
  2. If you don’t have a Copilot plan, the app asks whether to sign up for one or continue with your own model provider. If you pick your own provider, select it, enter its credentials and click Save and continue.
  3. Select repositories. The app suggests repositories based on your recent GitHub activity. You can also add a local folder, or skip this step and add repositories later.
  4. Choose a theme and finish onboarding.

Step 3: Learn the sidebar in two minutes

According to the quickstart, the sidebar has these areas:

Sidebar itemWhat it’s for
NewStart a new agent session.
My workIssues and pull requests from your repositories, with CI status and reviews.
AutomationsSaved agent tasks that run on a schedule or on demand.
CustomizePlugins, skills, MCP servers (connections to outside tools) and canvases.
SearchSearch across your repositories.
SessionsYour connected repositories and folders, with their active agent sessions.
ChatsPlain conversations that don’t create a branch or workspace.

Projects also appear in the sidebar with their own + button. Recent release notes renamed things: what used to be called “Persistent Agents” are now Projects, and the old “projects” are now called repositories (or folders and collections). If an older tutorial or video uses the old names, that’s why.

Step 4: Connect a repository or folder

An agent needs something to work on. In the sidebar, next to Sessions, click + and choose one of three options:

  • Open local folder. Pick a folder already on your computer, including a repository you cloned earlier.
  • Add GitHub repository. Browse and clone a repository from your GitHub account.
  • Clone repository. Paste a Git URL. Use this for repositories outside GitHub (Azure DevOps, for example) or for private repositories the app doesn’t have access to yet.

You don’t need to be a programmer for this to be useful. A folder of Markdown documents, a website’s content files or a spreadsheet export can all be “the repository” an agent works in.

Step 5: Start your first session

Here’s the flow from the agent sessions guide, in the order the controls appear:

  1. Next to Sessions, click +. Under “Start session in”, select your repository or folder.
  2. Open the Environment dropdown below the prompt box and choose This computer or Cloud (more on this choice below).
  3. Open the Workspace dropdown and choose New worktree (a separate working copy, which is safest) or Current checkout (work directly in the folder as it is). You can also choose the base branch.
  4. Choose a session mode, a model and a reasoning effort from the dropdowns under the prompt.
  5. Type the task. Use # to reference an issue, @ to attach a file, and / for commands.

GitHub’s own suggested first prompt is a good, safe test:

Suggest a small low-risk code change in this repository, implement it, and explain the diff.

When the agent finishes, click Changes above the prompt box to see exactly what it changed. Keep chatting in the same session until you’re happy, then click Create PR. After that, click PR above the prompt box to see the pull request inside the app.

You can also start from an existing task: open My work, pick an issue, and start a session from it.

Which session mode to pick

The mode controls how much the agent checks in with you:

ModeWhat happensUse it when
InteractiveYou and the agent work together; it suggests changes and waits for your input.You’re learning the app or the task is fuzzy.
PlanThe agent writes a plan first; you approve it before anything runs.The task touches many files, or you want to agree on scope before spending credits.
AutopilotThe agent works on its own: writes, tests and iterates without waiting.The task is well defined and low risk.

You can switch modes at any time. GitHub’s cost advice follows the same order: validate scope in Plan, steer in Interactive, and move to Autopilot only when the task is clear.

Tool permissions: the setting that matters most for safety

Session mode is not the same as tool permissions. Tool permissions decide when Copilot asks before it runs a terminal command, edits files, fetches a web page or hands work to another agent. There are three levels:

  • Ask every time (manual approval): the most oversight and the most prompts.
  • Assisted: a model looks at each request, approves the ones it judges safe and asks you about the rest. As of v1.1.31 this is available to everyone.
  • Approve all: runs tools without asking. Convenient, but you lose oversight of individual actions.

To change it for one session, click the mode under the prompt field, hover over Tool permissions and pick a level. To set the default for future local sessions, open the app settings, click Sessions, and choose under Tool permissions.

Our recommendation: start with Assisted. It removes most of the approval clicks for harmless actions like reading files, and it still stops for anything risky. Only use Approve all in a cloud session or a sandboxed local session, where a bad command can’t reach the rest of your computer. If you want to understand the trade-offs in more depth, our guide to Claude Code permission modes covers the same idea for another agent.

Step 6: Choose a model (and when to use Copilot Fusion)

Click the model name below the prompt box. You have two options.

Copilot Fusion. Turn on the Copilot Fusion switch and pick an effort level. Fusion is a router: for each prompt it decides which model, or which combination of models, should handle it. GitHub’s Fusion docs describe three patterns it can use:

  • Single: one model does the job.
  • Cascade: a cheaper model drafts, a judge checks the draft and escalates to a stronger model only if needed.
  • Critique: one model drafts while several others critique it in parallel, then the draft is revised.

The effort levels, and which plans get them:

Effort levelBest forPlans
Fusion StandardEveryday work; picks one model per task.All plans, including Free and Student
Fusion HighSubstantial, well-scoped tasks such as a complex bug or a multi-file change.Pro+, Max, Business, Enterprise
Fusion MaxThe hardest problems that need the deepest reasoning.Pro+, Max, Business, Enterprise

There’s also a time-limited discount: through November 30, 2026, paid plans get 30% off model costs when using Copilot Fusion. There’s no separate charge for Fusion itself; you pay each model’s normal rate. High and Max can call more than one model per task, so they can cost more per task than Standard.

A specific model. Turn the Fusion switch off and pick a model from the list. Some models also let you set effort and context-window size. Your choice takes effect right away if the agent is idle, or when the current turn finishes, and it becomes your default for new sessions (existing sessions keep their own model).

Two Fusion gotchas from the docs:

  1. If Fusion discards a draft, file edits that draft already made are not undone automatically. Always read the Changes view before you commit.
  2. To see which models actually ran, hover over the effort-level name under the response.

Step 7: Decide between this computer and the cloud

The Environment dropdown is the decision that most affects safety and convenience.

This computer runs the agent on your machine. Use it when the agent needs local tools, a running dev server, or desktop apps (computer use only works in local sessions). You can make local sessions safer with local sandboxing, which limits the filesystem, network and credentials the agent’s tools can reach. Turn it on per repository in settings, or type /sandbox on in an active session.

Cloud runs the whole session in an isolated Linux environment hosted by GitHub. The cloud sandbox docs list what you get:

  • It uses none of your computer’s resources, so you can run several heavy sessions in parallel.
  • You don’t need to stay connected. A stopped session keeps a snapshot and resumes with your files intact.
  • You can follow and steer it from any Copilot client (the app, GitHub Mobile, github.com, VS Code).
  • Commands in the sandbox can’t read or change files on your computer.

Cloud sandboxes are billed by usage on three meters: compute at $0.000024 per vCPU-second, memory at $0.000003 per GiB-second, and snapshot storage at $0.005 per GiB-month. You choose the environment when the session starts and can’t change it later; start a new session to switch.

Pitfall: blocked websites in the cloud. Cloud sandboxes follow the same firewall allowlist as Copilot cloud agent. If the agent needs a site that isn’t allowed, add it to the allowlist, then start a new session. Allowlist changes don’t apply to sessions that are already running.

Step 8: Give Copilot a goal with Projects (public preview)

Projects are the headline Universe feature. A session is one task in one repository. A project is an ongoing goal that can span several repositories, or none at all, and Copilot decides how many sessions and automations it needs. From the projects guide:

  1. In the sidebar, next to Projects, click +. The New project page opens.
  2. Optionally, under Which repositories should this Project use?, pick suggested repositories or search, then click Add repositories. You can skip this for work that doesn’t involve code.
  3. Optionally, add reference material first: click the Library tab in the right-hand panel, click Add, then Add file… or Add folder….
  4. Describe the goal and the first tasks, including the result you want and any limits. Then send.

GitHub’s example is a good template for non-coding work:

I want to use this project to investigate customer
feedback about our new search feature and decide
what to improve.

First, review the feedback document in this project's
library. Group the feedback by theme and summarize
the main problems customers describe.
For each theme, include supporting examples from the
document and suggest questions we should investigate.
Use only the provided feedback. Do not make code changes.

Notice the last two lines. “Use only the provided feedback” stops the agent from inventing data, and “Do not make code changes” stops it from opening pull requests you didn’t ask for. Add guardrails like these to every project prompt.

Tracking progress. Click Overview in the right-hand panel. Work is grouped as Needs input (decisions, reviews and permission requests waiting on you), Open (work with an open pull request, showing lines added and deleted), Working and Done. Check Needs input first, because agents waiting on you aren’t making progress. Click any session to see its conversation, changes, pull request and plan, or type into Steer this session to redirect it.

Library. Under All Files, User holds what you added and Agent holds what Copilot created. Keep only material relevant to the goal in there, and tell Copilot which files to use for each task.

Recurring work inside a project. Just ask in the project conversation, for example: “Every Monday at 9 AM in my local time zone, review the customer feedback in this project’s library and create a summary grouped by theme.” Then open the Automations tab in the right-hand panel to confirm the schedule and next run time. To change it, either ask in plain language (“run every Friday at 10 AM instead”) or use the menu next to the task: Pause, Edit schedule… or Delete….

Per the Universe changelog, you can also pull in context from connected tools like Slack and Figma, and generate or edit images in chat.

Step 9: Set up an automation (with a spending cap)

Automations are saved agent tasks that run on a schedule, in response to repository events, or when you click play. A classic example from the automations guide: triage new issues every day, or check your open pull requests’ review status every morning.

There are two kinds:

  • Local automations run on your computer, so your computer has to be on.
  • Cloud automations run in GitHub’s cloud and keep running while your computer is off. They require Copilot cloud agent to be enabled for the repository (Business and Enterprise admins must enable that policy).

The easy way: let Copilot design it

  1. Click Automations in the sidebar, then Create automation in the top-right corner.
  2. From the dropdown under the prompt box, choose the repository.
  3. Describe in plain language what you want automated.
  4. Under Type, choose Personal or Shared (explained below).
  5. Click Start session. Copilot asks you questions and sets up the trigger, tools and prompt.

The manual way

Click Create manually, name it, optionally turn on Run in the cloud, pick a Trigger, then fill in the prompt and choose the model, effort and agent. Click Create, or open the dropdown next to it and click Create and run to test it straight away.

Three settings that are easy to get wrong

1. Personal vs Shared (you can’t change it later).

PersonalShared
Who sees itOnly youEveryone with access to the repository
Who pays the AI creditsYouThe organization or user that owns the repository
Whose identity acts on GitHubYoursCopilot’s

2. Trigger permissions. For issue and pull request triggers in the cloud, you choose what the run can change: Anything in this repository or Only the triggering issue. Pick the narrower option whenever you can. Note that this limit doesn’t apply to tools from MCP servers, which can reach whatever their own credentials allow. You also choose Can be triggered by: Only people or People and Copilot. Since v1.1.33, new cloud automations require write access to trigger by default. Leave Require write access to trigger on unless you really want anyone with read access (on a public repository, that’s anyone) to set off a paid agent run.

3. Tools. New cloud automations start with no optional tools selected, so tool access is a deliberate choice. Pick only what the job needs, such as updating issue labels for a triage bot. The Suggest tools button (new in v1.1.33) adds tools based on your instructions without removing ones you already picked.

Put a ceiling on cost

For cloud automations, expand AI credit limits under the prompt box. All limits are optional and measured in AI credits:

  • Per run: stops a run as soon as it hits the limit. The minimum is 30 credits.
  • Daily: blocks new runs once reached; resets at 00:00 UTC (08:00 Beijing time).
  • Weekly: resets Mondays at 00:00 UTC.
  • Monthly: resets on the 1st at 00:00 UTC.

Daily, weekly and monthly limits don’t stop a run that’s already going. Only the per-run limit does. If you’re worried about one runaway run, set a per-run limit. Local automations can’t have credit limits.

Privacy warning from GitHub’s docs: cloud automation prompts and session logs are visible to everyone with read access to the repository, even for Personal automations. Never paste passwords, API keys or customer data into an automation prompt.

To run any automation right now, click the play button on its card. To see what the last run did, right-click the automation and choose View last session.

Step 10: Let Copilot use your desktop apps (computer use, public preview)

Computer use lets Copilot read what’s on screen in a desktop app, click buttons, type, scroll, drag and move between apps. It’s meant for software without an API or command line: an old internal tool, an expense system, a GUI-only admin panel. It works in local sessions on macOS and Windows (not Linux, and not cloud sessions). Copilot works in the background, so you can keep using other apps; on Windows it briefly brings the target app to the front only when it needs to.

To turn it on (computer use guide):

  1. Open the app’s settings and select Computer Use in the sidebar.
  2. Turn on Enable Computer Use.
  3. On macOS, under Prerequisites, grant both Accessibility (to control buttons) and Screen Recording (to see windows). If the app doesn’t notice you granted them, click Check again.

Shortcuts: /computer on and /computer off in a session, and /computer show to check status.

Write the prompt as an outcome with clear limits, like GitHub’s example:

Open APP_NAME and summarize the status information shown in the
main window. Do not change any values or submit any forms.

When Copilot asks to control an app, check that the app and action match your request, then choose Allow (this session only), Always allow (saved for future sessions) or decline. To stop it mid-action, click Stop or press Esc.

Gotchas:

  • Always allow is shared. An app you always-allow in the Copilot app is also always-allowed in Copilot CLI on the same computer. To remove it, go to Settings > Computer Use > Always allowed apps and click the delete icon.
  • Removing an app doesn’t stop a running session. It only affects future sessions. Press Esc or end the session to revoke access right away.
  • Settings page missing? The feature may not be available for your account or operating system yet. At work, your organization can disable it through managed settings.
  • Mac: it can’t click anything? Make sure both permissions show Granted under Prerequisites.

Start with read-only tasks (“summarize”, “find”, “list”) before you let it submit forms. The same caution applies to any agent with control of your apps; we cover the browser version of this trade-off in our guide to letting AI agents use your logged-in Chrome.

Using your own model (BYOK) or a local model

If you have no Copilot plan, or want to use a model GitHub doesn’t offer, add a provider: open Settings > Model providers > Add provider, pick the provider, enter the details (display name, base URL, API key) and click Add provider. Supported providers include OpenAI, Azure OpenAI, Microsoft Foundry, Anthropic, Ollama, Foundry Local, LM Studio and any OpenAI-compatible endpoint. Keys go into your operating system’s credential store and aren’t shown in the app. BYOK is in public preview.

Windows PCs with an NVIDIA GPU and plenty of memory can also download local coding models (such as MAI Code 1.1 Flash) under Settings > Model providers > Add provider > Windows ML. Local models don’t use AI credits, but the setup needs llama.cpp and at least 48 GB of RAM, so most readers can skip it.

What it costs, in plain numbers

The app itself is free. What you pay for is the AI work, measured in GitHub AI Credits (1 credit = $0.01). From GitHub’s billing docs:

PlanPrice/monthTotal monthly AI credits
Copilot Free$0A small allowance; auto model selection only
Copilot Pro$101,500 (1,000 base + 500 flex)
Copilot Pro+$397,000 (3,900 base + 3,100 flex)
Copilot Max$10020,000 (10,000 base + 10,000 flex)

Credits reset at 00:00 UTC on the 1st of each month (08:00 Beijing time) and don’t roll over. Long Autopilot sessions on frontier models use credits much faster than a quick chat on a small model. For how budgets and hard stops work, see our GitHub Copilot AI Credits guide.

For companies: GitHub announced that, starting October 28, GitHub Enterprise customers can use all Copilot features, including the app, code review and automations, without buying a separate Copilot subscription, paying only for the AI credits they use. For now this goes through GitHub Sales; self-serve is “coming soon”. Existing Copilot Business and Enterprise customers can keep their current plans.

Five habits that save credits

These come from GitHub’s own cost guidance for the app:

  1. Match the model to the job. Light models (or Fusion Standard) for small edits; stronger models for hard debugging and design decisions.
  2. Scope in Chats first. A Chat doesn’t create a branch or workspace. Talk through a fuzzy idea there before opening a full session.
  3. Plan before Autopilot. A quick Plan-mode pass catches a wrong approach before the agent spends credits building it.
  4. One task per session. Start a new session when you switch tasks so old, irrelevant context isn’t sent with every message.
  5. Check your habits weekly. Type /chronicle cost tips to find your most expensive patterns. /chronicle standup summarizes recent work, handy before a team meeting.

Troubleshooting common problems

“I can’t sign in with my company’s GitHub.” If it’s GitHub Enterprise Server (self-hosted), the app doesn’t support it. If it’s GitHub Enterprise Cloud with data residency, choose Use GitHub Enterprise and enter your *.ghe.com hostname.

“The app says I don’t have access, but Copilot works in VS Code.” For Business and Enterprise seats, the GitHub Copilot app policy must be enabled. It’s separate from the CLI policy, so ask your admin.

“I can’t create a cloud automation.” Copilot cloud agent must be enabled for the repository, and the organization must allow both cloud agent and automations there.

“A cloud session can’t reach a website.” Add the host to the firewall allowlist, then start a new session.

“WSL environments don’t show up.” Run gh auth login inside your WSL distribution (that sign-in is separate from the Windows app), then go to Settings > Environments and click Connect. If Environments is missing, check Settings > Experimental and make sure WSL hosts is on.

Anything else: report it in the github/app Issues tab with your app version, OS, steps to reproduce and /collect-debug-logs output. Remove anything sensitive from the logs first.

Should you switch to it?

If your work already lives on GitHub, this is the easiest way to run several agents at once and still see what each is doing, and Copilot Free plus BYOK make it cheap to try. Start with one repository, Assisted permissions, Plan mode and Fusion Standard. Add a cloud automation with a per-run limit once you trust the results, and keep computer use to read-only jobs for now.

Sources