Copilot Automations can now be shared by a team: they belong to the repository, bill the repository's owner and keep running if the creator leaves
Automations that only their creator could see can now be maintained as team assets, which suits locking in flows like reproducing a bug whenever an issue is opened.
// Key points
- Each automation combines prompts, triggers and tools, and Copilot runs it autonomously in the cloud with only the tools the team allows; example triggers are an issue opening, a PR marked ready and a production incident from a monitoring tool.
- Anyone with read access can see a shared automation and anyone with write access can edit it; actions are attributed to Copilot, and change history tracks prompts, triggers and tools.
- AI credits bill the organization or user that owns the repository; organization repositories need an admin to enable the Allow use of Copilot cloud agent billed to the organization policy.
- It is rolling out to Copilot Pro, Pro+, Max, Business and Enterprise, and the type cannot be changed after creation.
Builder's takeOwnership moving from a person to the repository is the real change here: automations no longer leave with people, but the costs quietly land on the organization. Set an organization budget for the Copilot cloud agent before enabling the policy, and start with read-only flows such as an incident triggering an automatic investigation.
// Background · from #Coding agents
Full timeline →- Oct 31 Claude Code 2.1.314 adds a setting that blocks writes outside the working directories in every permission mode
- Oct 31 GitHub Actions workflow lockfiles are generally available: keep readable tag references while running only the locked commits, transitive dependencies included
- Oct 31 GitHub Agent Merge comes to pull requests: Copilot watches a PR in the cloud and fixes failing Actions workflows and merge conflicts