What happened
GitHub added comment triggers for Copilot cloud agent automations on August 3. An automation is a standing rule you set up once, and Copilot’s cloud agent (a version of Copilot that runs tasks in the background instead of waiting for you to type in a chat) carries it out whenever the trigger fires.
Until now, those triggers were things like opening a pull request (the page where a proposed code change sits before a team reviews and merges it) or applying a label. Now a comment on an issue or pull request can start one too. You pick the trigger text yourself when you set it up. GitHub’s own examples: comment on a pull request to generate or update documentation for the code change, comment on an issue to have the agent investigate an error log or stack trace, or comment on a pull request to spin up follow-up issues for cleanup work later.
To set one up, open your repository’s Agents tab, choose Automations, and define the comment text that should fire it. GitHub supports these automations in private and internal repositories. The automation docs exclude public repositories. Automations are available on Copilot Pro, Pro+, Max, Business, and Enterprise. On Business and Enterprise, an administrator has to turn on the Copilot cloud agent policy before anyone on the team can use it.
Why it matters
An automation that fires on a comment runs without anyone directly starting a task, which is exactly why GitHub built in a default restriction: automations ignore comments from anyone who doesn’t have write access to the repository. Write access means someone can push code directly to the repository, a step above just opening a pull request from a fork (their own separate copy of your repo, which is how outside contributors usually propose changes). That default keeps an outside commenter on an eligible private or internal repository from being able to set off an automation just by typing the right words in a comment.
GitHub also lets you turn that restriction off, so the automation responds to anyone’s comment, including people without write access. Allowing commenters without write access broadens who can start an agent task. That creates a prompt-injection risk: text the agent reads can steer it toward an unintended action. If any commenter can trigger an agent task, someone could try to phrase a comment to steer what the agent does once it starts, not just whether it starts.
Two protections carry over regardless of that setting. Anything the automation produces, a pull request it opens or code it pushes, is attributed to whoever created the automation, not to the commenter who triggered it. That person still can’t approve their own pull request, so normal review rules hold. And you choose which tools an automation can use when you set it up, so you can limit what it’s capable of doing even if it does fire on an unexpected comment.
Who should care
This matters for private or internal repositories where some contributors can comment but cannot push code. The default excludes trigger comments from users without write access. Turning that restriction off lets more people start agent tasks, so review the task and tool scope first.
It matters less if your repo is private with a small, trusted team, all of whom already have write access. In that case, changing this restriction does not alter which current team members can trigger tasks. Their comments and any external content the agent reads still need appropriate handling.
What builders should do next
Before you set up a comment-triggered automation, open your repository’s Copilot cloud agent settings and confirm the write-access restriction is still on, especially if the repo takes contributions from anyone outside your immediate team. If you’ve already set up an automation, check that setting now rather than assuming the default held.
Then test it deliberately. Set up a trigger comment for documentation generation on a small pull request. Have someone with write access post the trigger, and separately, if you have a test account without write access, have that account try the same comment. Confirm the automation only fires for the first case, that the resulting pull request is attributed to the automation’s creator and not auto-approved, and that the tools it used match what you scoped it to. That gives you a real answer for your repo’s actual permission setup instead of assuming the default protects you.
End of article