Copilot CLI drops the PAT requirement inside GitHub Actions

GitHub announced that Copilot CLI inside GitHub Actions workflows can now authenticate using the built-in GITHUB_TOKEN instead of requiring a personal access token (PAT). This change, noted in the July 2 changelog, eliminates the need for human-owned credentials, reducing security risks and operational overhead. The update applies only to Copilot CLI within Actions, not to other environments.

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 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. 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. 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. 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. 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.