Fix GitHub Actions 'Resource not accessible by integration'
The Error
A GitHub Actions workflow step fails with:
Error: Resource not accessible by integration
This typically appears when a step tries to create a release, push a package, comment on a PR, or modify repository contents using the built-in GITHUB_TOKEN.
Root Cause
GitHub Actions provides an automatic GITHUB_TOKEN for each workflow run. This token's permissions are controlled at three levels:
- Organization/repository default permissions - Admins can restrict the default token to read-only.
- Workflow-level
permissionsblock - When present, it overrides defaults and grants only what is explicitly listed. - Job-level
permissionsblock - Overrides the workflow-level block for that specific job.
The error occurs when the token lacks the specific permission needed for the API call. Since GitHub tightened defaults in 2023, many repositories now default to read-only tokens.
Step-by-Step Fix
1. Identify what permission is needed
Check the failing step's documentation. Common mappings:
| Action | Required permission |
|---|---|
| Create a release | contents: write |
| Comment on a PR | pull-requests: write |
| Push a package | packages: write |
| Update commit status | statuses: write |
| Modify issues | issues: write |
| Push to the repo | contents: write |
2. Add permissions to the workflow file
Add a permissions block at the workflow or job level:
name: Release
on:
push:
tags: ['v*']
permissions:
contents: write
jobs:
release:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Create Release
uses: softprops/action-gh-release@v2
with:
generate_release_notes: true
If multiple permissions are needed:
permissions:
contents: write
pull-requests: write
packages: write
3. Check repository-level settings
Go to Settings > Actions > General > Workflow permissions in your repository. Ensure it is set to "Read and write permissions" or that your explicit permissions block covers what you need.
For organization-managed repos:
Organization Settings > Actions > General > Workflow permissions
4. Handle fork-based pull requests
Workflows triggered by pull_request from forks always receive a read-only token regardless of your permissions block. This is a GitHub security restriction. For fork PRs, use pull_request_target instead (with caution):
on:
pull_request_target:
types: [opened, synchronize]
Warning: pull_request_target runs with the base branch's code and full write access. Never check out and execute untrusted fork code with this trigger.
5. If using a Personal Access Token (PAT) instead
When GITHUB_TOKEN is insufficient (cross-repo access, triggering other workflows), use a PAT or GitHub App token:
steps:
- uses: actions/checkout@v4
with:
token: ${{ secrets.MY_PAT }}
Prevention Tips
- Always declare
permissionsexplicitly. Do not rely on repository defaults. Explicit permissions make workflows portable and self-documenting. - Follow the principle of least privilege. Only grant the permissions each job actually needs. Use job-level blocks if different jobs need different scopes.
- Audit workflows after enabling restrictive defaults. When switching an org to read-only defaults, test all existing workflows to catch breakages.
- Use GitHub Apps over PATs. App tokens offer fine-grained permissions, are scoped to specific repositories, and do not depend on a single user account.
Was this article helpful?
DevSecOps Lead
Security-first mindset in everything I ship. From zero-trust architectures to supply chain security, I make sure your pipeline doesn't become your weakest link.
Related Articles
Fix GitHub Actions Workflow Stuck in 'Queued'
Diagnose and resolve GitHub Actions workflows that remain stuck in 'queued' status, covering runner availability, concurrency limits, and label mismatches.
The Complete Guide to GitHub Actions CI/CD: From Zero to Production-Ready Pipelines
Build production-grade GitHub Actions CI/CD pipelines — from first workflow to reusable workflows, matrix builds, and deployment gates.
GitHub Actions Reusable Workflows and Composite Actions for DRY Pipelines
Eliminate duplicated CI/CD logic across repositories using GitHub Actions reusable workflows and composite actions with real-world examples.
Hardening GitHub Actions: Permissions, OIDC, and Pinned Actions
Harden GitHub Actions security with least-privilege permissions, OIDC federation, SHA-pinned actions, and secrets management best practices.
GitHub Actions Matrix Builds for Multi-Platform Testing
Master GitHub Actions matrix builds to test across multiple OS versions, language versions, and configurations in parallel.
GitLab CI Dynamic Child Pipelines For Monorepo Microservices Deployment
After a decade of wrestling with CI/CD systems and watching monorepo deployments go from "simple" to "nightmare" and back to "elegant," I've seen every per...
More in CI/CD
View all →GitLab CI Pipeline Optimization: Caching, DAG, and Parallel Jobs
Cut your GitLab CI pipeline time from 25 minutes to 6 with smart caching, DAG dependency graphs, parallel test splitting, and stage optimization.
Automated Semantic Versioning with Conventional Commits and release-please
Stop manually bumping versions. Use conventional commits and release-please to automate versioning, changelogs, and releases.