Security & supply chain

Copilot CLI drops the PAT requirement inside GitHub Actions

Copilot CLI drops the PAT requirement inside GitHub Actions

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)

Related
Security & supply chain

Dependabot can finally pull from private GitHub Packages without a PAT

GitHub gave Dependabot its own GITHUB_TOKEN access to private GitHub Packages and GHCR, retiring one of the most awkward credentials in any CI setup. For pipeline owners, that closes a quiet but persistent rotation tax.

June 24, 2026
Security & supply chain

GitHub Agentic Workflows drop personal access tokens for the built-in Actions token

Agentic workflows on GitHub can now authenticate with the ephemeral GITHUB_TOKEN instead of a long-lived personal access token. It is a quiet credential-hygiene win that closes one of the messier blast radii in agent-driven CI.

June 15, 2026
Security & supply chain

libcurl drops NTLM in September 2026, and on-prem Azure DevOps Git over HTTPS goes with it

Microsoft has warned Azure DevOps Server customers that Git operations over HTTPS will break for anyone still authenticating with NTLM once libcurl removes the protocol in September 2026. Build agents, workgroup boxes and service accounts are the ones most likely to hit the wall.

July 3, 2026

Turn this into your pipeline. Build it on Buddy.

Start free