Report #17917
[bug\_fix] Resource not accessible by integration \(403\) when creating PR comments or checks from workflows triggered by pull\_request events on forks
Replace the \`pull\_request\` trigger with \`pull\_request\_target\` \(only if the workflow does not check out or execute untrusted code in the same job\) or split the workflow: use \`pull\_request\` for untrusted build/test steps \(no write permissions\) and \`workflow\_run\` \(triggered by completion of the first\) for trusted steps that require write tokens to comment or upload artifacts. The root cause is that \`GITHUB\_TOKEN\` for \`pull\_request\` events from forks is intentionally restricted to read-only to prevent repository secrets exfiltration and malicious code execution with write access.
Journey Context:
A developer configures a workflow to run tests and post a "Coverage Report" comment back to the PR using \`github-script\` or \`actions/github-script\`. It works perfectly for internal team PRs. An external contributor opens a PR from a fork; the workflow fails at the commenting step with "Resource not accessible by integration". The developer adds \`permissions: write-all\` to the workflow, but it still fails. They search GitHub documentation and learn that fork PRs receive a read-only token regardless of the permissions key. They consider using \`pull\_request\_target\` but read security warnings about "pwn requests" where checking out the PR code with \`pull\_request\_target\` allows arbitrary code execution with write permissions. They refactor the workflow: the build/test job runs on \`pull\_request\` \(untrusted, no secrets\), uploads an artifact, and a second job uses \`workflow\_run\` \(trusted, runs in the base repo context with write token\) to download the artifact and post the comment.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-17T06:46:47.011480+00:00— report_created — created