Seeing the Resource not accessible by integration error in GitHub Actions usually means that a workflow or one of its actions is trying to access a GitHub resource without the required permissions. You might encounter it when creating a pull request, commenting on an issue, updating repository contents, or uploading code scanning results.

The fix depends on the operation that failed. In many cases, you need to adjust the workflow’s permissions, but pull requests from forks, Dependabot workflows, and organization policies can introduce additional restrictions.

Here is how to identify the cause and fix it without giving your entire workflow unnecessary access.

1. Find the step that produced the error

Open your repository on GitHub, select the Actions tab, and open the failed workflow run. Expand the failed step and look for the exact error message and the operation it was performing.

For example, the error might appear while an action attempts to create a pull request, post a comment, modify a file, or upload security analysis results.

Those operations do not all require the same permissions. Before editing your workflow, identify which step failed and which resource it was trying to access.

2. Check the GITHUB_TOKEN permissions

GitHub Actions automatically provides a token called GITHUB_TOKEN for authenticating workflow operations. Its permissions determine what the workflow can do through GitHub’s APIs.

Open the workflow YAML file, usually stored under .github/workflows/, and inspect its existing permissions configuration.

For a workflow that needs to read repository files and create or update pull requests, the configuration might look like this:

name: Pull Request Automation

on:
  pull_request:
  workflow_dispatch:

permissions:
  contents: read
  pull-requests: write

jobs:
  automate:
    runs-on: ubuntu-latest
    steps:
      - name: Check out repository
        uses: actions/checkout@v4

      - name: Run automation
        run: echo "Run your pull request automation here"

This example grants read access to repository contents and write access to pull requests. Change these permissions according to the operation your workflow actually performs; this configuration is not a universal fix for every integration error.

Important: When you explicitly list permissions in the workflow, any permissions you leave out are set to none. If an existing workflow already has a permissions block, add only the missing permission rather than replacing the whole block without checking what other steps need.

3. Grant the permission required by the specific operation

The correct permission depends on what the workflow is trying to do. Some common examples are:

• Read repository files: Start with contents: read.
• Create or update repository files: The workflow may need contents: write.
• Create or update pull requests: The workflow may need pull-requests: write, and some operations may also require contents: write.
• Manage issues or comments: Depending on the API operation, issues: write or pull-requests: write may be required.
• Upload code scanning results: The workflow commonly needs security-events: write, subject to the event and workflow context.

These permissions are not interchangeable. For example, granting permission to write repository contents does not automatically authorize every pull request or issue operation.

Check the documentation for the action or GitHub API endpoint involved in the failed step before adding permissions.

4. Check whether the workflow runs on a pull request from a fork

If the error happens only on external pull requests, the event that triggered the workflow may explain the problem.

For security reasons, GitHub normally restricts the token available to workflows triggered by pull requests from public forks to read-only access. Adding a write permission to the YAML file does not override this restriction.

Consequently, an action that works when you push to your own branch may fail when it tries to publish a comment, create a pull request, or modify a file during a forked contribution.

Do not solve this by blindly switching to a privileged event or exposing secrets to untrusted pull request code. A safer design is to separate the untrusted build or test job from any privileged operation. If a privileged follow-up is necessary, validate the inputs and carefully limit what that separate workflow can access.

5. Check Dependabot and code scanning workflows

Dependabot pull requests have additional security considerations, which can affect automation that expects write access.

If the error appears while uploading code scanning results, first confirm that the workflow grants the required security-events: write permission when appropriate.

GitHub documents a specific case where Dependabot-triggered code scanning workflows fail with this error. For those workflows, GitHub recommends using the pull_request event rather than the push event for the relevant analysis runs.

Do not apply that event change to every workflow automatically. Follow the guidance for the specific Dependabot or code scanning scenario you are troubleshooting.

6. Check repository or organization settings

Even a correctly configured YAML file may not be enough if repository or organization settings restrict the workflow.

For a repository you administer, open Settings → Actions → General and inspect the workflow permissions configuration. An administrator may have set restrictive defaults or applied an organization-level policy.

If your workflow specifically needs to create or approve pull requests using GITHUB_TOKEN, check whether the repository allows GitHub Actions to create and approve pull requests. This setting is separate from the permissions declared in the workflow file.

Make changes only when the intended operation requires them, and use the narrowest access that will work.

7. Check whether the workflow is accessing another repository

The automatically provided GITHUB_TOKEN is scoped to the repository containing the workflow. It does not automatically grant access to every repository in your organization.

If your workflow is trying to update another repository, publish an artifact elsewhere, or call an API for a resource outside its permitted scope, increasing permissions on the current repository’s token may not be sufficient.

Depending on the task, you may need a GitHub App installation token or a suitably scoped personal access token stored as a repository or organization secret. Give the credential access only to the repositories and operations it needs, and never print the token in logs.

Quick troubleshooting checklist

• Identify the exact action and API operation that failed.
• Inspect the workflow-level and job-level permissions settings.
• Grant only the permission needed for the failed operation.
• Check whether a fork or Dependabot pull request triggered the run.
• Review repository and organization policies if the YAML looks correct.
• Verify whether the workflow is accessing a different repository.

Frequently asked questions

Why does GitHub Actions work locally but fail on GitHub?

Local commands run using your own environment and credentials, while a GitHub Actions workflow uses its configured token and permissions. A command that succeeds with your local account may be denied when the workflow runs with restricted access.

Should I set every GitHub Actions permission to write?

No. Broad permissions increase the impact of a compromised action or workflow. Grant the minimum permissions needed for each operation and consider using job-level permissions when different jobs require different access.

Will adding permissions always fix this error?

No. Fork-related restrictions, Dependabot security rules, repository policies, unsupported operations, and cross-repository access can cause similar errors. Diagnose the failed operation before changing the configuration.

Conclusion

The GitHub Actions “Resource not accessible by integration” error is usually a sign that an automated operation lacks the access it needs, but the correct fix depends on the trigger, token, resource, and repository settings.

Start by identifying the failed API operation, then check the relevant GITHUB_TOKEN permission. If the workflow runs on a fork, uses Dependabot, or accesses another repository, investigate those restrictions before changing the workflow’s security model.

For the latest details, read GitHub’s official documentation on workflow permissions, GITHUB_TOKEN, and the specific resource-not-accessible code scanning error.