GitHub Copilot Automations add shared team workflows, 24 new triggers and AI credit limits
GitHub has expanded Copilot Automations, the feature that lets Copilot cloud agent run tasks on its own in response to a schedule, a repository event or an API call, with a set of changes announced on October 28, 2026 alongside the company's GitHub Universe releases. The update introduces shared automations that belong to a repository rather than to an individual developer, adds 24 new GitHub event triggers and 20 new GitHub tools, opens automations to external systems through a REST trigger and to custom MCP server tools, and gives teams spending limits measured in AI credits at the level of a single run, a day, a week or a month.
Two further changes extend where and how automations run. In Visual Studio Code 1.144, automations created in the editor can now run in the cloud, so scheduled tasks keep going when the laptop is closed or switched off. GitHub has also introduced self-improving automations: an automation can study the signals its own work leaves on GitHub, such as whether developers accept its review comments or merge its pull requests, and propose changes to its prompt, tools or triggers, which a human must accept before they take effect.
All of the new capabilities are listed for the Copilot Pro, Pro+, Max, Business and Enterprise plans. GitHub describes shared automations as rolling out, with availability that may vary while the rollout progresses, and none of the October 28 changelog entries labels the feature set as a preview or as generally available.
··········
FROM PERSONAL SCHEDULED TASKS TO REPOSITORY WORKFLOWS.
Automations first appeared on June 2, 2026, when GitHub let Copilot cloud agent run without a person starting each task. At launch the triggers were limited to an hourly, daily or weekly schedule, the creation of a new issue, and the opening or updating of a pull request. Each automation was scoped to one repository, it worked only in private and internal repositories, and its token usage was billed to the person who created it at standard usage-based rates.
That design made automations a personal tool. An automation acted with its creator's identity, consumed its creator's AI credits and was visible only to that person, which suited an individual developer's recurring chores but not a team process that needs to outlive a single contributor. The October update is aimed squarely at that gap, and GitHub's documentation now describes an automation as a combination of a name, a type, a prompt, triggers, tools, an optional model and reasoning level, and optional AI credit limits.
The documentation also draws a line between automations and GitHub Agentic Workflows, which became generally available in the same Universe release cycle. Automations are stored separately from the repository's contents and are not committed to Git, so they are not versioned or reviewed through pull requests. Teams that want workflows stored as code, reviewed like any other change or executed by a different coding agent are pointed to Agentic Workflows instead.
··········
HOW SHARED AUTOMATIONS DIFFER FROM PERSONAL ONES.
A shared automation is created by choosing "Shared" under "Type" on github.com, in the GitHub Copilot app or in Visual Studio Code, and anyone with write access to a repository can create one there. The type is fixed at creation: an automation cannot later be converted from personal to shared or the other way round. Because the automation belongs to the repository, it keeps running if the person who built it leaves the team or loses access, and a change history records how its prompt, tools and triggers have evolved.
The practical differences are about who sees the automation, who pays for it and whose name appears on its actions. GitHub's documentation summarises them as follows.
........
Property | Personal automation | Shared automation |
Who can see it | Only the creator | Everyone with read access |
Who can edit it | Only the creator | Everyone with write access |
AI credits billed to | The creator | Repository owner (organization or user) |
Identity on GitHub | The creator | Copilot |
Survives creator leaving | No | Yes |
........
The billing change matters most for organizations. For an organization-owned repository, an administrator must first enable the policy named "Allow use of Copilot cloud agent billed to the organization" before shared automations can run, because their AI credits are charged to the organization rather than to the developer who wrote the prompt. When a personal account owns the repository, the credits go to that owner's Copilot subscription. In both cases each run starts a cloud agent session that consumes GitHub AI credits as well as GitHub Actions minutes, and the Actions minutes are billed separately to the repository owner.
The examples GitHub gives for shared automations are the kind of chores a team usually assigns informally: reproducing a bug as soon as an issue is opened, capturing screenshots of a change when a pull request is marked ready, or investigating a production incident when a monitoring tool detects it.
··········
24 NEW EVENT TRIGGERS AND AN API ENTRY POINT.
The trigger list grows substantially. Beyond the original schedule, issue-created and pull-request events, GitHub has added 24 event triggers spread across issues, pull requests, discussions and security alerts.
........
Area | New trigger events |
Issues | Assigned, sub-issue added, labeled, closed, reopened, status changed |
Pull requests | Assigned, ready for review, labeled, merge conflict, review submitted, requested or dismissed, closed, reopened, converted to draft, review thread resolved or unresolved |
Discussions | Opened, updated, comment or reply created |
Security alerts | Code scanning, secret scanning and Dependabot alerts created |
........
Event triggers can be narrowed with search-query filters, and pull request triggers accept a filter on changed files, so an automation can be limited to, for instance, changes under a particular directory. By default, events caused by users who do not have write access to the repository are ignored, a setting GitHub explains as a way to reduce the risk of prompt injection from outside contributors; repository owners can opt in to those events deliberately.
Automations can now also be started from outside GitHub. A "Trigger an automation" REST endpoint can be called from a webhook handler, and the documentation says extra context can be passed into the prompt when an automation is triggered this way. GitHub's own examples are triaging Jira tickets, fixing new Sentry issues and investigating PagerDuty incidents, which turns automations into a bridge between an issue tracker or monitoring system and the repository where the fix will land. The REST reference for agent automations also documents endpoints to list, create, read, edit and delete automations and to list the tasks an automation has run.
The third addition is chaining. A new "Can be triggered by" setting defaults to users only, but it can be switched to users and Copilot, so that an event produced by another automation, such as a pull request opened by Copilot, is allowed to fire the trigger. Two dedicated triggers, "Automation run succeeded" and "Automation run failed", let one automation start when another finishes. The default protects teams from accidental loops in which automations keep triggering each other, and enabling chaining is an explicit decision.
··········
NEW TOOLS, MCP SERVERS AND THE PERMISSION MODEL.
Triggers decide when an automation runs; tools decide what it is allowed to do. GitHub has added 20 GitHub tools, including uploading image or video attachments to issues and pull requests, retrying workflow runs, merging pull requests, editing issue and pull request comments, marking pull requests ready for review or converting them to drafts, hiding and unhiding comments and reviews, removing reactions, and reading, listing and commenting on discussions. The ability to merge pull requests and retry workflow runs is the most consequential of these, because it lets an automation finish a task rather than only prepare it for a human.
Automations can also use tools exposed by custom MCP servers. A server is added in the repository's MCP settings and its tools are then selected individually in the automation's tool picker. The documentation is explicit about the difference in scope: GitHub tools operate only inside the single repository the automation belongs to, while MCP server tools are not limited to that repository and can reach whatever the server's configuration and credentials allow. The guidance is to grant only the tools a task needs, and a "Suggest tools" button proposes a tool set based on the prompt.
Several safeguards sit around automation output. Pull requests created by shared automations require an additional approval by default when the repository already requires at least one approval; administrators can remove that requirement through rulesets but not through classic branch protection rules. A personal automation's actions are attributed to its creator, who cannot approve the resulting pull requests. GitHub Actions workflows do not run on pull requests created by an automation until a user with write access approves them, and every cloud agent session started by an automation, including its prompt, logs and changes, is visible to anyone with read access to the repository. Automations also inherit the repository's cloud agent configuration: custom instructions, agent skills, firewall rules, and secrets and variables.
··········
AI CREDIT LIMITS AND WHAT AUTOMATIONS COST TO RUN.
The cost controls address the main risk of putting an agent on an event trigger in a busy repository: a burst of issues or pull requests can start many runs in a short time. Limits are expressed in AI credits, are optional, and can be combined.
........
Limit | Behaviour | Reset |
Per run | Stops a run when it reaches the limit (minimum 30 AI credits) | Each run |
Daily | Blocks new runs once reached | 00:00 UTC |
Weekly | Blocks new runs once reached | Monday 00:00 UTC |
Monthly | Blocks new runs once reached | 1st of the month, 00:00 UTC |
........
The documentation adds one detail that matters for budgeting: daily, weekly and monthly limits do not stop a run that is already in progress. A team that wants a hard ceiling therefore needs a per-run limit alongside the periodic ones, since a single long session could otherwise overshoot a daily budget. Automations without limits keep running as they did before, and limits can be set on github.com or in the GitHub Copilot app. GitHub's announcement does not state a price or conversion rate for AI credits, so the monetary value of a given limit depends on the plan's AI credit terms; the shift to credit-based billing for Copilot access was covered in our report on GitHub Enterprise plans including Copilot access with AI credits billed from the first request.
··········
CLOUD AUTOMATIONS IN VISUAL STUDIO CODE.
Visual Studio Code already supported local personal automations that ran on a schedule on the developer's own machine. From version 1.144, automations can also run in the cloud and can be created and managed from the Automations tab of the editor's Agents window. Three things become possible from inside the editor: scheduled personal automations that keep running while the computer is asleep or off, personal automations triggered by GitHub events such as an issue being assigned to the developer or a pull request being opened, and shared team automations that act as Copilot.
To use them, developers update to Visual Studio Code 1.144, enable the `chat.automations.cloud.enabled` setting and open the Automations tab in the Agents window. The same plan list applies: Copilot Pro, Pro+, Max, Business and Enterprise.
··········
SELF-IMPROVING AUTOMATIONS AND HUMAN APPROVAL.
The most experimental part of the release is the ability of automations to learn from outcomes. GitHub's premise is that it is easy to create an automation but harder to build one a team can trust, and that the evidence of whether an automation works is already visible on GitHub. For issue triage, the signal is whether people change the labels the automation applied; for code review, whether developers accept its comments; for performance work, whether maintainers merge the pull requests it opens.
When a developer asks Copilot to set up a self-improving automation, Copilot can create a group of automations that work together. GitHub's example for a custom code reviewer pairs a review automation that runs on every opened pull request with a weekly improvement automation that analyses how developers responded to the review comments and proposes refinements. The improvement automation can propose changes to the original automation's prompt, its tools or its triggers. GitHub sends a notification when a change is proposed, and each proposal can be accepted or rejected before it is applied. The documentation adds that automations can also propose changes when they run into problems such as a missing tool.
GitHub has not documented how long outcome signals are retained or whether the cadence of the improvement automation can differ from the weekly example, and those details will determine how quickly such a loop actually converges on better behaviour.
··········
WHAT CHANGES FOR DEVELOPERS AND COPILOT ADMINISTRATORS.
For individual developers on Copilot Pro, Pro+ or Max, the update mainly widens what a personal automation can react to and do: more event triggers, external triggers through the API, MCP tools, cloud execution from Visual Studio Code and spending caps. Personal automations remain billed to the developer and act under the developer's identity, so the per-run and periodic limits are the first settings worth configuring before attaching an automation to a busy event such as pull request reviews.
For organizations on Copilot Business or Enterprise, shared automations require deliberate administrative choices. Copilot cloud agent must be enabled for the repository, the organization must allow both cloud agent and automations (both are on by default), and the policy allowing cloud agent usage billed to the organization must be switched on before shared automations can run in organization-owned repositories. Administrators should also review whether the default extra approval on automation-created pull requests fits their rulesets, and which MCP servers are configured in repositories, since MCP tools can reach beyond the repository.
The existing limits still apply. Automations are available only in private and internal repositories, not in public ones; they cannot run where a repository administrator has disabled them, in repositories owned by managed user accounts, or where cloud agent is not enabled. Teams already using automations alongside Copilot Fusion's automatic model routing can still pin a specific model and reasoning level per automation, since both remain optional settings.
··········
TECHNICAL SYNTHESIS.
What GitHub has documented is a clear evolution of Copilot Automations from personal scheduled tasks into a repository-level workflow system: shared ownership with organization billing and Copilot attribution, 24 additional event triggers, an external REST trigger, chaining between automations, 20 new GitHub tools plus MCP tools, AI credit limits per run and per period, cloud execution from Visual Studio Code 1.144, and a self-improvement loop gated by human approval. The plan coverage, the private-and-internal-repository restriction, the reset times of the limits and the security defaults are all stated in the official documentation.
Several points remain open. GitHub has not attached a general-availability label to the expanded feature, shared automations are still rolling out, and no price per AI credit is given in the announcement, which leaves the real cost of a busy event-driven automation dependent on each plan's credit terms. The self-improvement mechanism is described through examples rather than measured results, so its effect on review quality or triage accuracy is not yet established. What is certain is that the controls teams need to run agents unattended, namely explicit tool grants, spending ceilings, approval gates and visible session logs, are now part of the product rather than something each team has to build around it.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
