Copilot CLI drops the PAT requirement inside GitHub Actions
Maya Okonkwo
GitHub said this week that Copilot CLI, when it runs inside a GitHub Actions workflow, will accept the built-in GITHUB_TOKEN for authentication. Per the July 2 changelog, the previous path required creating and storing a personal access token. The operational read is small and precise: one fewer human-owned credential to mint, rotate and inherit.
The exact scope of the change
The changelog covers a narrow surface. It applies to Copilot CLI when invoked from a GitHub Actions workflow, and it swaps the required credential from a PAT to the workflow's ambient GITHUB_TOKEN. GitHub does not describe changes to how Copilot CLI authenticates outside Actions, and this post will not extrapolate to those contexts. If your Copilot CLI usage lives on a developer laptop or in another CI system, nothing in this announcement moves for you.
Why the PAT was the wrong credential to leave in the loop
A personal access token has almost none of the properties you would want from an automation credential. It does not expire on a job boundary. It carries a person's identity, not the workflow's. It sits in Actions secrets long enough to outlive the engineer who created it. And its scopes were chosen by that engineer, at that moment, often wider than the job actually needs.
GITHUB_TOKEN is the opposite shape. Actions mints it at the start of a job, scopes it through the workflow's permissions: block, and revokes it when the job ends. If the token leaks, the window for abuse is the runtime of the job, not the years until somebody remembers to rotate it. When the person who wrote the workflow leaves, the pipeline does not silently break because a token expired with their account.
For scripted Copilot CLI calls that had to be wrapped in a PAT, that is the whole win. The tool authenticates against the workflow instead of against a human.
Wiring it up
The workflow-side pattern is the same one every GITHUB_TOKEN-consuming step already follows: declare permissions: explicitly at the job level, keep them as narrow as the job needs, and pass the token in through the environment.
jobs:
copilot-task:
permissions:
contents: read
pull-requests: write
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@<full-40-char-sha>
- name: Run Copilot CLI
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
# invoke the Copilot CLI here
Nothing above is a magic incantation. It is the same permissions declaration the platform has documented for years, applied to a new consumer.
What this does not fix
The PAT category is not gone. Any Copilot CLI call that has to cross a repository boundary still needs a credential that reaches further than GITHUB_TOKEN, whose scope is the current repository. Any workflow driving third-party APIs still has to authenticate against those APIs, and no changelog on github.com moves that. And the announcement does not speak to Copilot CLI running outside Actions, so the local-dev token conversation is unchanged.
There is also the general caution that comes with every credential swap: read the permissions: block carefully. GITHUB_TOKEN is short-lived, but if a workflow grants it contents: write because that felt easier than thinking about it, an agentic step that goes off-script can still push to main. The token is scoped, but the scope is what you set it to.
The wider pattern
Other CI platforms have been iterating on the same shape from different starting points. GitLab CI has offered a job-scoped CI_JOB_TOKEN for calls back to the GitLab API for years, and ID tokens for OIDC federation to cloud providers. Buildkite, CircleCI and others expose OIDC identity for cloud roles rather than shipping a bag of static credentials to the runner. The direction is not controversial. Long-lived, human-owned tokens are the credential every audit eventually flags, and the CI ecosystem has been walking away from them one integration at a time.
This changelog is one more of those. Copilot CLI-in-Actions is a small enough surface that most teams will notice it as one less rotation on the calendar, not as a policy inflection. That is the point.
Source: GitHub Changelog (github.blog)