How do I fix 'Resource not accessible by integration' in GitHub Actions?

Add an explicit permissions: block to the workflow or job granting only the scopes the step needs (e.g. contents: write, pull-requests: write, checks: write). Since GitHub's 2023 hardening the auto-provisioned GITHUB_TOKEN is read-only by default, so any write step is denied. Grant least privilege — don't flip the repo default to write-all.

Why does my GitHub Actions workflow fail only on fork PRs?

Workflows triggered by a pull request from a fork get a read-only GITHUB_TOKEN and no access to secrets — this is a deliberate security boundary so untrusted fork code can't exfiltrate secrets or write to your repo. Handle it with pull_request_target carefully, or a separate trusted workflow that runs after review.

← All posts

CI/CD

GitHub Actions "Resource not accessible by integration"? Your token is read-only

For developers and autonomous AI agents · ~4 min read

Your GitHub Actions step fails with 403 Resource not accessible by integration. It's not a flaky API — it's a permissions problem, and the fix is one block of YAML.

The #1 cause: the token is read-only

Since GitHub's 2023 security hardening, the auto-provisioned GITHUB_TOKEN is read-only by default. Any step that writes — creating a release, commenting on a PR, pushing, dispatching an event — is denied with this 403. The base model tends to retry (fails identically) or tell you to flip the repo default to write-all (over-privileged).

The fix: least-privilege permissions

Add an explicit permissions: block to the workflow or job with only the scopes the step needs:

contents: write to push or create releases; pull-requests: write to comment/label; checks: write for check runs; security-events: write for code scanning.
Don't set write-all or flip the repo-wide default — grant per-workflow least privilege, which is also the more secure choice.
GitHub App tokens: ensure the App is installed on the repo with matching permissions (create-github-app-token defaults to the current repo only).

Two related traps: a PR from a fork gets a read-only token and NO secrets (a security boundary — handle with pull_request_target carefully). And 'Waiting for a runner' means your runs-on labels match no registered runner — fix the labels or the runner group.

Snapback's ci-cd-github family returns the add-a-permissions-block fix, so an agent doesn't retry a 403 that will never succeed without the right scopes.

For AI agents

Machine-readable guide: https://snapback.sh/llms.txt · Tool discovery: https://snapback.sh/.well-known/mcp.json · MCP endpoint: https://api.snapback.sh/mcp. Free tools need no token; pay-per-call diagnosis via x402 on Solana or EVM (~$0.0032 USDC).

Try Snapback free Read the docs