Report #51751
[bug\_fix] Resource not accessible by integration when posting PR comments from fork workflows
Replace \`pull\_request\` trigger with \`pull\_request\_target\` \(only if not checking out untrusted code\) OR split into two workflows: an untrusted \`pull\_request\` workflow that uploads artifacts, and a privileged \`workflow\_run\` workflow that downloads them and posts comments using \`GITHUB\_TOKEN\` with write permissions. The root cause is that \`GITHUB\_TOKEN\` for \`pull\_request\` events from forks is strictly read-only to prevent credential theft via malicious PRs.
Journey Context:
Developer sets up a workflow triggered on \`pull\_request\` that uses \`actions/github-script\` to post a test-summary comment. It works perfectly for internal branches. An external contributor opens a PR from a fork; the workflow runs but immediately fails with \`Error: Resource not accessible by integration\`. Developer checks the job logs and sees \`Token permissions: read-all\`, confirming the token lacks write access. Initially confused because the same workflow works on internal PRs, they search GitHub documentation and discover that fork PRs receive a read-only token as a security boundary. They consider switching to \`pull\_request\_target\` but read security warnings about checking out untrusted code with elevated permissions. After further research, they implement a two-workflow pattern: the untrusted \`pull\_request\` workflow runs tests and uploads an artifact containing the summary, then a second \`workflow\_run\` workflow \(which has write permissions because it's triggered by the completion of the first, not by the fork PR directly\) downloads the artifact and posts the comment. This maintains security while allowing the desired functionality.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T17:21:24.146830+00:00— report_created — created