GitHub Actions · Checked November 3, 2026

GitHub Actions: "Resource not accessible by integration"

The token the step used, usually the job's GITHUB_TOKEN, does not have the permission that one API call needs, so GitHub answered 403. The fix is usually one line under permissions:. Which line depends on the call, and on what started the run.

What it looks like

From a public run on November 1, 2026, where actions/configure-pages failed:

##[error]Get Pages site failed. Please verify that the repository has Pages enabled and configured to build using GitHub Actions, or consider exploring the `enablement` parameter for this action. Error: Resource not accessible by integration - https://docs.github.com/rest/pages/pages#get-a-apiname-pages-site

The same refusal as other tools print it:

GraphQL: Resource not accessible by integration (removeLabelsFromLabelable)
gh: Resource not accessible by integration (HTTP 403)
RequestError [HttpError]: Resource not accessible by integration

"Integration" means a GitHub App. GITHUB_TOKEN is an installation token of the GitHub Actions app, and it can reach only the repository the workflow runs in. A fine-grained personal access token that lacks a permission gets "Resource not accessible by personal access token" instead (which permission that token lacks).
The job runs normally up to that call. The build and the tests before it may have passed.

Finding the permission it needed

Open the failed job, expand Set up job, then GITHUB_TOKEN Permissions. It lists what the token had. In the Pages run above it had only:
```
GITHUB_TOKEN Permissions
Contents: read
Metadata: read
```
The 403 response carries an X-Accepted-GitHub-Permissions header that names what the endpoint accepts. Commas join permissions needed together (pull_requests=write,contents=read), and a semicolon separates alternatives. actions/github-script prints the response headers with the error; one scheduled workflow that created an issue showed 'issues=write' (memphis #638). With gh, -i prints the headers even when the call fails:
```
gh api -i "repos/$GITHUB_REPOSITORY/pages"
```
The header uses API names with an underscore. In the workflow they are written with a hyphen: pull_requests=write is pull-requests: write.

Why the permission was missing

A permissions block left it out. From GitHub's workflow syntax reference: "If you specify the access for any of these permissions, all of those that are not specified are set to none." So adding permissions: contents: read to a workflow takes away every write the job had before. A Lock Threads workflow granted issues: write and pull-requests: write, but its action also processes closed discussions and the repository has Discussions, so every run failed until discussions: write was added (DynamicData #1212). A reusable workflow can keep or reduce the caller's permissions but never raise them, so the line belongs in the calling job (llm-d-kv-cache #743).
The default is read only. Under Settings, Actions, General, "Workflow permissions" is either read and write for all permissions (permissive) or read only for contents and packages (restricted), and organization owners can restrict it further. With the restricted default and no permissions block, every write fails. A release-drafter workflow failed this way and needed contents: write and pull-requests: read (docker-buildkite-plugin #322).
The run got a read-only token whatever the workflow says:
- A pull_request from a fork gets a read-only GITHUB_TOKEN and no secrets. A private repository can turn on "Send write tokens to workflows from pull requests"; a public one cannot. One project's benchmark comment was refused on every pull request from a fork and posted on pull requests from its own branches; it now comments only when the head repository is its own and leaves the table in the job summary for forks (optbench #38):
```
- name: Comment on the pull request
  if: github.event.pull_request.head.repo.full_name == github.repository
```
  pull_request_target does get a write token from public forks, and GitHub warns against checking out the fork's code in it.
- Runs started by Dependabot from push, pull_request, pull_request_review or pull_request_review_comment are treated like forks: a read-only token and no Actions secrets. Unlike forks, the permissions key can raise the token for them.

The permission for common tasks

Add or remove a label on a pull request: pull-requests: write. The labels endpoint is shared with issues, so the header can read issues=write; pull_requests=write, yet two public reports show issues: write alone refused on a pull request (llm-d-kv-cache #743, StellarCred #955).
Create an issue, or comment on one: issues: write. Comment on a pull request: pull-requests: write.
Create or update a release, push a commit or a tag: contents: write.
Lock or close discussions: discussions: write.
GitHub Pages: pages: read for actions/configure-pages; pages: write and id-token: write for actions/deploy-pages.
Upload a SARIF file to code scanning: security-events: write, plus actions: read and contents: read in a private repository.
Create a check run: checks: write. Set a commit status: statuses: write.
Publish to GitHub Packages: packages: write. Get an OIDC token to sign in to a cloud: id-token: write. Cancel a workflow run: actions: write.

Grant it on the job that makes the call, and repeat the reads that job still needs, since everything not listed becomes none:

jobs:
  label:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write

What no permission fixes

Another repository. GITHUB_TOKEN reaches only the workflow's own repository; for another one, use a GitHub App token or a fine-grained personal access token stored as a secret.
Repository administration, such as reading branch protection. It is not among the permissions a workflow can grant.
"GitHub Actions is not permitted to create or approve pull requests" is a different message: the setting "Allow GitHub Actions to create and approve pull requests", under the same "Workflow permissions", is off. New repositories in a personal account start with it off.
A 403 "Must have admin rights to Repository." when downloading logs means the request carried no token at all, even for a public repository (logs and admin rights).

See failed jobs from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, so the step that was refused stands out, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

GitHub and GitHub Actions are trademarks of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with, sponsored or endorsed by GitHub, Inc. or JetBrains.

More: "Unable to resolve action" · "The operation was canceled" · "Must have admin rights to Repository" · Re-running jobs with debug logging · GitHub Actions plugins for IntelliJ IDEA compared · 日本語