How to Use GitHub Copilot Automations: The Beginner's Guide
CodexFuse Team · 2026-11-02T19:18:02.180Z · 16 min read min read
GitHub Copilot Automations run Copilot's cloud agent on a schedule, on repo events, or via API. A beginner's guide to the prompt-trigger-tools model, personal vs shared, credit limits, and self-improving automations.
GitHub Copilot Automations are the closest thing to hiring a tireless junior teammate for your repository: you write a prompt once, attach a trigger, pick the tools it may use, and Copilot's cloud agent runs it on a schedule, on a repository event, or from an API call — whether or not anyone is logged in. This copilot automations tutorial covers the full beginner arc: the mental model that makes the three building blocks click, how to create your first automation, the trigger and tool lists, how copilot automation AI credit limits keep spend predictable, what copilot scheduled workflows are best at, and how copilot self-improving automations propose their own upgrades. If you have never used Copilot itself, start with our GitHub Copilot beginner guide — automations are one of its agent-powered features, and the basics there make everything below easier.
What Is GitHub Copilot Automations, Exactly?
GitHub Copilot Automations are a GitHub-hosted way to run Copilot's cloud agent on a schedule, in response to repository events, or programmatically through an API. You define three things — a prompt, one or more triggers, and the tools Copilot may use — and GitHub runs your automation automatically whenever its trigger fires. An automation can act inside its repository: opening a pull request, labeling an issue, hiding a stale comment. The feature arrived at GitHub Universe on October 28, 2026, with shared automations (rolling out), two dozen GitHub triggers, tools from custom MCP servers, and optional AI credit limits.
The Three Building Blocks: Prompt, Triggers, Tools
Every automation is the same three pieces, and naming them out loud before you build saves you from the most common beginner confusion. It runs in GitHub's cloud, not on your laptop — say that once and the rest of the model falls into place.
| Building block | What you decide | Example |
|---|---|---|
| The prompt | The instructions Copilot follows on every run | "Reproduce this bug from the issue text, then propose a fix as a pull request." |
| The triggers | When the automation starts | Every morning at 9, when an issue is created, or when your monitoring tool calls the API. |
| The tools | What the automation is allowed to do | Label issues, upload attachments, read discussions, call your MCP servers. |
Two optional settings complete the picture: a model and reasoning level (which model does the thinking), and AI credit limits (how much spend you allow). Without limits, GitHub says automations "continue to run as they do today" — which is why the limits section below is not optional reading.
How Do You Create Your First Automation?
Start with the smallest useful workflow, not the cleverest: issue triage is the canonical first automation because the prompt is short, the trigger is obvious, and the stakes are low. GitHub's own example prompt is "Label this issue as a bug, an enhancement, or other, based on its content." Follow this arc:
- Open the Agents tab. On your repository's main page on GitHub, click Agents under the repository name, then choose Automations in the sidebar.
- Create automation. Click Create automation, then pick Create with agent (a chat window where Copilot asks what you want to automate) or Create manually (a form). Beginners should try the agent path first — it asks the right questions.
- Name it and choose the type. Give it a descriptive name, then pick Personal or Shared (the type can never be changed later — choose deliberately; the full trade-offs are in the personal-vs-shared section below).
- Set the triggers. For the first automation, pick "When an issue is created" and leave the filters at their defaults. You can add schedule and API triggers later.
- Write the prompt. One paragraph of plain instructions beats three pages of edge cases on day one. Tell it exactly what to do and what not to touch.
- Choose the tools. Start with only the GitHub tools the run needs — labeling an issue needs comment tools, not the kitchen sink. Click Suggest tools if you are unsure what the prompt requires.
- Set an AI credit limit. Set a small per-run limit (the minimum is 30 AI credits) before the first real run. This is your seatbelt.
- Test it. Click Run and pick a trigger to simulate. For a manual trigger you can type extra context that simulates an API call; other triggers ask for a resource URL, like the issue to triage.
You can also create and manage automations from the Automations tab in the GitHub Copilot app, the Automations tab in VS Code's Agents window (VS Code 1.144 or later with the chat.automations.cloud.enabled setting turned on), or the REST API.
What Triggers Can You Use?
Triggers are the automation's sense of time and events. GitHub's docs name the core set, and the October 28 launch added many more GitHub triggers alongside a REST API trigger that lets outside systems like Sentry or PagerDuty kick automations off.
| Trigger type | How it fires | Good first use |
|---|---|---|
| Schedule | Hourly, daily, or weekly on the clock | A nightly dependency-audit sweep of your main repository. |
| Issue created | Every new issue, with an optional search-query filter | Labeling and routing new bug reports. |
| Pull request opened | Every new PR, with search-query and files-changed filters | Running a verification checklist on new PRs. |
| Pull request synchronized | When new commits land on a PR | Re-checking the checklist after each push. |
| Manual | You (or a teammate) press run | On-demand reproductions before you trust a schedule. |
| API | An HTTP call from any system, with extra context passed into the prompt | Starting an incident investigation when monitoring fires. |
Two safety details matter from day one. First, automations can chain: one automation can run after another, so a triage automation can hand off to a fix-proposal automation. Second, the default prompt-injection guard: automations ignore GitHub events triggered by users who don't have write access to the repository. That default stops a drive-by issue from a stranger's account from spending your credits.
Should Your Automation Be Personal or Shared?
This is the one choice you cannot change later, so make it deliberately. GitHub's create-automation docs lay out the split plainly.
| Personal | Shared | |
|---|---|---|
| Who sees and edits it | Only you | Everyone with access to the repository |
| AI credits billed to | You | The organization or user that owns the repository |
| Actions on GitHub use whose identity | Your identity | Copilot's identity |
| Survives you leaving | No — it is yours | Yes — it belongs to the repository |
Shared automations exist for team workflows: a whole team builds the workflow together and keeps it running. Because a shared automation belongs to the repository rather than its creator, it keeps working if that person leaves the team or loses access. Three caveats travel with sharing: shared automations are rolling out, so availability may vary and your screen may not match the docs yet; in an organization, an admin must allow Copilot cloud agent billed to the organization before shared automations can run; and by default, PRs opened by a shared automation need an extra required approval, while a personal automation's PRs can't be self-approved. One more rule for both types: automation sessions are visible to everyone with read access, so never put secrets in the prompt.
What Tools Can an Automation Use?
Tools are the automation's hands — everything it can do on GitHub and beyond. GitHub's own tools cover the everyday repo operations: uploading attachments, hiding or unhiding comments and reviews, adding or removing reactions, reading and discussing in discussions. These are limited to the single repository where the automation is configured, which keeps blast radius small by design. The bigger story from the October launch: an automation can also use tools from the MCP servers configured in the repository's MCP settings, and those are not limited to that repository. That combination — repo-scoped GitHub tools plus open-ended MCP tools — is what lets an automation "open a pull request or label an issue" and also check an external status page before it does. If you are stuck on which tools your prompt needs, the Suggest tools button on the GitHub form reads your prompt and proposes a set.
How Do Copilot Automation AI Credit Limits Work?
An automation that runs while you sleep is wonderful; an automation that runs up a bill while you sleep is not. GitHub's answer is four credit limits you can set per automation, with the docs describing each in plain terms:
| Limit | What it does | Reset |
|---|---|---|
| Per run | Stops a run the moment it reaches the limit. Minimum 30 AI credits. | Every run |
| Daily | Prevents new runs from starting once reached. Does not stop a run already in progress. | 00:00 UTC each day |
| Weekly | Prevents new runs from starting once reached. Does not stop a run already in progress. | Monday at 00:00 UTC |
| Monthly | Prevents new runs from starting once reached. Does not stop a run already in progress. | First day of each month at 00:00 UTC |
GitHub quotes its own pricing unit at one cent per AI credit, consumed by input, output, and cached tokens at each model's published API rate. Seats for Copilot Business and Enterprise, GitHub says, include that seat's dollar amount in monthly credits, pooled across the team. The spend-truth line worth remembering comes from Shashi Bellamkonda's launch coverage: "a scheduled automation running across forty repositories consumes credits at 2 a.m. with nobody logged in." That is his illustrative claim, not a tested figure — but the shape of it is exactly right, and it is why his recommendation of a named owner for automation spend, separate from developer-initiated spend, is the single best piece of team advice in this whole guide. Automations are available on Copilot Pro, Pro+, Max, Business, and Enterprise; each run also consumes GitHub Actions minutes, billed separately to the repository owner.
What Are Copilot's Self-Improving Automations?
GitHub's most unusual claim about automations is that they can get better on their own. You can add automations to automation groups, which share context and, in GitHub's words, "can suggest improvements to themselves based on outcomes." Concretely: automations can propose improvements to their own tools, triggers, and prompts — and to those of other automations in the group. When a proposal exists, you get a notification and see it when viewing the automation, and you decide whether to apply it or dismiss it. Say this once, because it is the line beginners misread: self-improving automations PROPOSE changes — a human reviews and approves every one. DevOps.com's Mike Vizard describes the same idea as automations that "learn from outcomes to propose improvements to those workflows." Treat it as a review queue for your automations, not as autopilot for your process.
How Do You Test an Automation Before It Goes Live?
The Run button is your staging environment. Click it and pick which trigger to simulate: a manual trigger lets you type extra context that simulates what an API call would send into the prompt, while event triggers like "issue created" ask for a resource URL — the actual issue you want the automation to practice on. Run it there, read the session output, tighten the prompt, and only then let the schedule loose. The docs' three named use cases make excellent practice runs: attempt to reproduce a reported bug when an issue is opened; capture screenshots of changes and attach them to a pull request marked ready for review; or start investigating an incident when your monitoring tool detects it.
What Do You Need Before You Start?
Automations are a paid-plan, private-repo feature, so check the checklist before you write a prompt — most "why can't I see automations?" questions end here.
| Requirement | The rule |
|---|---|
| Plan | Copilot Pro, Pro+, Max, Business, or Enterprise. |
| Repository | Private or internal only — automations are not available in public repositories. |
| Your access | Write access to the repository (you can create; read-access users can see sessions). |
| Copilot cloud agent | Must be enabled for the repository; the organization must allow it (both on by default). |
| Shared automations | Rolling out — GitHub says availability may vary; orgs need the "bill Copilot cloud agent to the organization" policy. |
| VS Code cloud automations | VS Code 1.144 or later with chat.automations.cloud.enabled enabled. |
Cloud sandbox compute billing begins in November 2026 as a separate meter from AI credits, per GitHub's launch coverage — budget for both if you schedule heavily.
What Are Copilot Scheduled Workflows Good For?
Schedule triggers are the feature's superpower: hourly, daily, or weekly, the agent shows up and works. The beginner-friendly hits are the ones where the trigger replaces something a human currently remembers to do. Issue triage every morning — the docs' example prompt is "Label this issue as a bug, an enhancement, or other, based on its content." A nightly verification loop over open pull requests: "whenever a pull request is opened, an issue is closed, or an event occurs anywhere on the platform, you can build a custom verification loop around it," as GitHub COO Kyle Daigle described it in an October 2026 interview. Dependency sweeps, stale-issue gardening, screenshot capture on PRs marked ready for review — all schedule-shaped work. Save the event-driven and API-driven automations for the second week; scheduled ones teach you the prompt-and-tools loop with the calmest feedback cycle.
How Are Automations Different from VS Code Agent Automations and CLI Scripting?
The word "automation" now names three different GitHub surfaces, and mixing them up is the fastest route to a wrong architecture. First, VS Code 1.137's September 2026 "recurring agent automations" preview: those execute locally — the sources describe them needing an active agent host or a running VS Code window, and the machine must stay awake. GitHub's own Copilot app docs draw the line as local automations, which run from your local environment, versus cloud automations, which run in a cloud environment. Second, Copilot CLI scripting (copilot -p run inside GitHub Actions workflow files) is local automation: you write the script, the workflow runs it. Cloud Automations are the opposite shape: GitHub hosts the prompt, trigger, and tools — no workflow file, no script, no machine to keep awake. No source describes a migration path between the local and cloud surfaces, so don't plan for one. And within the October 28 Universe family, keep the lanes straight: Copilot Automations is the repo-workflow engine (prompt plus triggers plus tools), Copilot Fusion is the model router that picks which model answers, and Copilot Code Review Max is the review lane — our Copilot Code Review Max guide covers that one. If you manage automations from the Copilot app, our GitHub Copilot app guide maps the interface.
7 Beginner Mistakes That Waste Credits
| Mistake | Why it hurts | The fix |
|---|---|---|
| No credit limits on day one | A looped or chatty prompt spends all night. | Set a per-run limit (minimum 30 AI credits) before the first real run. |
| Secrets in the prompt | Automation sessions are visible to everyone with read access. | Reference integrations by name; never paste tokens or keys. |
| Choosing Shared "just in case" | Type can never be changed; shared bills the repo owner and attributes actions to Copilot. | Start Personal, convert the idea to Shared only when the team owns it. |
| The whole-repo default tools | An automation that can do everything can break everything. | Use Suggest tools, then delete anything the prompt doesn't need. |
| Trusting the self-improvement queue blindly | Proposals change triggers and prompts — your spend shape follows. | Review every proposal; apply or dismiss deliberately. |
| Public-repo expectations | Automations simply don't exist on public repositories. | Use a private or internal repo; check the org's cloud-agent policy. |
| Forgetting Actions minutes | AI credits are only half the meter; runs also consume GitHub Actions minutes. | Budget both when a schedule fans out across many repos. |
For the broader Copilot universe around automations, see our GitHub Actions guide for the CI-shaped sibling of cloud automations, and our GitHub beginner guide for the write-access and repository-admin basics this feature assumes.
Sources
- GitHub Docs, "Copilot automations" (concepts page) — https://docs.github.com/en/copilot/concepts/agent-capabilities/agent-powered-workflows-and-operations/about-automations
- GitHub Docs, "Creating automations with Copilot cloud agent" (how-to page) — https://docs.github.com/en/copilot/how-tos/use-copilot-agents/cloud-agent/create-automations
- GitHub Changelog, "Build shared workflows for your team with Copilot Automations" (October 28, 2026) — https://github.blog/changelog/2026-10-28-build-shared-workflows-for-your-team-with-copilot-automations/
- enjoy.dev, "GitHub Universe 2026: Copilot moves to the cloud, and sandboxes bill from November" — https://enjoy.dev/blog/github-universe-2026-copilot/
- Shashi Bellamkonda, "GitHub's New Copilot Pricing Ties Your Bill to Agent Activity" (October 28, 2026) — https://www.shashi.co/2026/10/githubs-new-copilot-pricing-ties-your.html
- Mike Vizard, DevOps.com, "GitHub Adds Tools to Manage AI Coding Agents Running in Parallel at Scale" — https://devops.com/github-adds-tools-to-manage-ai-coding-agents-running-in-parallel-at-scale
- AI World HQ, "What GitHub Copilot Automations and Copilot Fusion Are, and Who They're For" (October 30, 2026; updated November 1, 2026) — https://aiworldhq.com/article/what-github-copilot-automations-and-copilot-fusion-are-and-who-they-re
Frequently Asked Questions
Do GitHub Copilot Automations cost extra money?
They cost AI credits, which are GitHub's spending unit — GitHub prices one credit at one cent, consumed by input, output, and cached tokens at each model's published rate. Runs also consume GitHub Actions minutes billed to the repository owner, and cloud sandbox compute begins billing separately in November 2026. You set per-run, daily, weekly, and monthly credit limits on each automation; the daily, weekly, and monthly limits reset at 00:00 UTC (weekly on Monday, monthly on the first). All pricing details here are GitHub's stated claims — no independent tested spend figures exist for real automation runs yet.
Can I use Copilot Automations on a public repository?
No. GitHub's docs are explicit: automations are available in private and internal repositories only, never in public ones. They are also unavailable where a repository administrator has disabled them, in repositories owned by managed user accounts, or where Copilot cloud agent is not enabled. You need write access to the repository to create an automation.
What's the difference between personal and shared automations?
Personal automations are visible only to you, billed to you, and act under your identity. Shared automations are visible to everyone with repository access, billed to the organization or user that owns the repository, and act under Copilot's identity — and they belong to the repository, so they keep working if you leave. The type cannot be changed after creation, shared automations are still rolling out (availability may vary), and in organizations an admin must allow Copilot cloud agent billed to the organization first.
What are copilot scheduled workflows best at?
Work a human currently remembers to do: morning issue triage, nightly verification loops over open pull requests, dependency sweeps, stale-issue gardening, and screenshot capture when a PR is marked ready for review. GitHub's docs name three starter patterns — reproduce a bug when an issue opens, capture screenshots for review when a PR is ready, and investigate an incident when monitoring fires — and event-driven or API-driven triggers are the natural second step once the scheduled loop feels familiar.
Can an automation improve itself without me?
No — it can only propose. Automations in an automation group share context and can propose improvements to their own tools, triggers, and prompts, or to other automations in the group. You receive a notification, review the proposal when viewing the automation, and choose whether to apply it or dismiss it. Treat the self-improvement queue as review work, not autopilot.
