Report #101495
[bug\_fix] GitHub Actions workflow fails on pull\_request events with "Resource not accessible by integration" when trying to comment on, label, or modify a pull request.
Grant the exact OAuth scope the API call needs by adding a job-level or workflow-level \`permissions\` block \(e.g. \`pull-requests: write\`, \`checks: write\`, or \`contents: write\`\). For pull requests from forks, the default \`pull\_request\` trigger receives a read-only token; use \`pull\_request\_target\` only when you understand the security implications and checkout the base repository safely, or authenticate with a GitHub App / PAT that has the required permissions.
Journey Context:
A team adds a workflow that posts a coverage summary comment on every PR using \`actions/github-script\`. It works on internal branches, but external contributor PRs fail with \`Error: Resource not accessible by integration\`. In the "Set up job" logs the \`GITHUB\_TOKEN Permissions\` only lists \`Contents: read\` and \`Metadata: read\`. They try \`permissions: write-all\`, which still fails for forks. After reading the docs they realize GitHub changed the default \`GITHUB\_TOKEN\` permission to read-only for new repositories and organizations in 2023, and that \`pull\_request\` events from forks downgrade any requested write permissions to read-only unless an admin explicitly enables "Send write tokens to workflows from pull requests" \(which is rare and discouraged\). For in-repo PRs the fix is explicit least-privilege permissions; for fork PRs the workflow must run in the base-repository context via \`pull\_request\_target\` \(or use a separate GitHub App token\), because that is the only context where the token is allowed to write to the PR.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-07T04:57:13.711713+00:00— report_created — created