GitHub publishes instructions for automatically running Copilot CLI with Actions

GitHub documentation explains how to automatically run Copilot CLI with GitHub Actions. In the example, a workflow starts on a schedule at 5:30 p.m. UTC every day or through a manual trigger, then generates a summary of the day's repository changes. The generated content is written to summary.md and added to the GitHub Actions run summary.

The example limits workflow permissions to contents: read while separately allowing Copilot CLI to run git and write files. It also explains the two authentication options, GITHUB_TOKEN and PAT, concretely showing the need to design repository permissions and the CLI's operational scope separately.

The key point of the page is not simply how to invoke Copilot CLI, but how to present the trigger conditions, repository permissions, tools available to the CLI and destination for generated output as one end-to-end workflow. The example combines daily scheduled and manual runs, reads the git history, writes a summary of changes to a file and passes that content to the run summary. In other words, it shows an approach that makes CLI output easy to review later rather than merely leaving it in the logs. However, while GitHub recommends Agentic Workflows, the page also provides detailed instructions for running Copilot CLI with GitHub Actions. The page says Agentic Workflows use GITHUB_TOKEN authentication by default and include additional guardrails for automation, but does not give specifics about their configuration. By contrast, the Actions example sets contents: read while allowing the CLI to use a shell for git and to write files. Repository-wide permissions and the operations allowed to the agent are configured separately, making explicit control of the executable scope a key design consideration. The choice of authentication method is also tied to operational requirements. The documentation recommends GITHUB_TOKEN for organization-owned repositories and lists PAT as an alternative for cases such as policy restrictions or attributing usage to a specific user's Copilot account. When using a PAT, the instructions call for the “Copilot Requests” permission and storing the token as a repository secret. Thus, authentication design for the same CLI execution can vary depending on who manages the token and how usage is attributed. What remains unclear is the specific nature of the additional guardrails in Agentic Workflows and how to approve or validate files generated by this example before passing them to subsequent processes. The page cites creating pull requests and sending email as examples of next steps, but does not explain execution conditions or safeguards against incorrect changes. When connecting generated output to notifications or repository updates, the permissions granted and who reviews the results will determine how the process differs from the read-focused summary task shown in the example.

The example runs in ubuntu-latest. It specifies fetch-depth: 0 for actions/checkout@v6 and configures the Node.js environment with actions/setup-node@v7. Copilot CLI is installed with npm install -g @github/copilot, and permissions are set to contents: read. The documentation describes two authentication methods: GITHUB_TOKEN and a personal access token (PAT). In the PAT example, a token with the “Copilot Requests” permission is stored as a repository secret and set as COPILOT_GITHUB_TOKEN. The run command specifies --allow-tool='shell(git:*)' and --allow-tool=write, and uses --no-ask-user to suppress input prompts during automated runs. The documentation recommends Agentic Workflows, which use GITHUB_TOKEN authentication by default and include additional guardrails for automation environments.