Report #70410
[bug\_fix] Workflow steps that post PR comments, upload SARIF/code-scanning results, or write checks fail with 'Resource not accessible by integration' only for pull requests from forks; the same workflow works for branch-based pull requests.
Grant the minimum required \`permissions\` for the action \(for example \`pull-requests: write\` for PR comments, \`security-events: write\` for SARIF uploads, or \`checks: write\` for status checks\). For public fork PRs GitHub still restricts write access by default, so move the write step into a \`workflow\_run\` workflow that executes in the base repository context after the PR workflow completes, or use \`pull\_request\_target\` with strict safeguards and never check out untrusted PR code directly.
Journey Context:
You add a linter that posts a helpful comment back to the PR. It works when you test from the same repository, but external contributors see 'Resource not accessible by integration'. You add \`permissions: pull-requests: write\` and it still fails for forks. You read the token docs and learn that fork PRs on the \`pull\_request\` event receive a read-only token regardless of the \`permissions\` block, and that you can only add read permissions for forks through the workflow file. The safe pattern is to split the workflow: the untrusted \`pull\_request\` job runs the linter and uploads the comment body as an artifact, then a trusted \`workflow\_run\` job reads the artifact and posts the comment using the base repository's write token. For CodeQL SARIF uploads you apply the same split so the upload step has \`security-events: write\` in the base context.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T00:46:09.604607+00:00— report_created — created