GitHub Actions "Resource not accessible by integration": give the token the right permission

1. Which permission?

Look at which step failed, and what it does:

If you’re not sure, GitHub tells you. On a REST API call, the response header x-accepted-github-permissions lists what the endpoint accepts. Look for it with curl -i or gh api -i.

2. Set it in the workflow

The permissions key can sit at the top, for all jobs, or better, on the job that needs it:

permissions:
  contents: read

jobs:
  release:
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v7
      - run: gh release create "$GITHUB_REF_NAME" --generate-notes
        env:
          GH_TOKEN: ${{ github.token }}

Two details catch people out:

• Setting permissions turns everything you don’t list to none. Add pull-requests: write alone, and a private repository’s actions/checkout can start failing, because contents: read is gone.
• Avoid permissions: write-all. It works, but a compromised action could then do anything the token can. Ask for the smallest set.

The CI/CD Pipeline Generator writes workflows this way, read-only by default, with packages: write only on the job that pushes an image.

3. Pull requests from forks

Here adding permissions won’t help. On a pull_request event from a fork, the token is always read-only, whatever the workflow says, and repository secrets aren’t available. That’s what stops a stranger’s pull request from changing your repository.

So how do you comment on those pull requests? Split the work in two:

• A pull_request workflow runs the untrusted code, with no permissions, and uploads the result as an artifact.
• A workflow_run workflow, which runs from your default branch with write access, reads that artifact and posts the comment.

Dependabot has the same treatment: its pull_request runs get a read-only token, and its own set of secrets, under Settings → Secrets and variables → Dependabot. Its token can be raised with permissions on pull_request_target, or on a workflow triggered another way.

4. Repository and organization settings

Check Settings → Actions → General → Workflow permissions. “Read repository contents and packages permissions” is the default, and “Allow GitHub Actions to create and approve pull requests” is a separate box: without it, creating a pull request fails with a similar message, even with pull-requests: write.

An organization can lock these settings, in which case they’re greyed out for the repository, and an organization owner has to change them. permissions in a workflow can’t go above what they allow.

5. When GITHUB_TOKEN isn’t enough

The token only reaches its own repository. To open issues in another one, read a private repository or a private package elsewhere, use a GitHub App token (actions/create-github-app-token), or a fine-grained personal access token, stored as a secret:

- run: gh issue create --repo acme/other --title "Build failed" --body "See the run"
  env:
    GH_TOKEN: ${{ secrets.OTHER_REPO_TOKEN }}

And an action might not use the token you think: check its token input.