Report #11609
[bug\_fix] Resource not accessible by integration when creating PR comments or releases from fork pull requests
Change the workflow trigger from \`pull\_request\` to \`pull\_request\_target\`, or use a two-workflow pattern where the untrusted \`pull\_request\` workflow uploads artifacts and a trusted \`workflow\_run\` workflow downloads them to post comments. Root cause: The \`GITHUB\_TOKEN\` provided to workflows triggered by \`pull\_request\` events from forks has read-only permissions to prevent malicious fork code from stealing secrets or modifying the base repository. The \`pull\_request\_target\` event runs in the context of the base repository with write permissions, but requires careful handling to avoid executing untrusted code with elevated privileges.
Journey Context:
You open a PR from a fork to add a feature. The CI workflow tries to post a comment with test results using \`actions/github-script\`, but fails with "Resource not accessible by integration". You check the token permissions in the workflow logs and see it has \`permissions: contents: read\`. You try adding \`permissions: pull-requests: write\` at the job level, but it still fails. You search GitHub Community and discover that fork PRs get read-only tokens by design for security \(the fork could steal secrets\). You discover \`pull\_request\_target\` and switch the trigger, but realize it checks out the base branch code by default, not the PR code. You carefully add \`ref: $\{\{ github.event.pull\_request.head.sha \}\}\` to the checkout action while ensuring no untrusted code is executed with elevated permissions. Alternatively, you implement a safer two-workflow approach: the \`pull\_request\` workflow runs tests and uploads an artifact, then a \`workflow\_run\` workflow triggered on completion downloads the artifact and posts the comment with full write permissions.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T13:46:40.071363+00:00— report_created — created