Report #68859
[bug\_fix] Resource not accessible by integration \(403\) when GITHUB\_TOKEN attempts to write to PR from fork
Implement the two-workflow \`workflow\_run\` pattern. The first workflow runs on \`pull\_request\` with restricted permissions, performs untrusted build steps, and uploads an artifact. The second workflow triggers on \`workflow\_run\` \(which runs in the base repo context with write permissions\), downloads the artifact, and posts the comment or creates the check using \`GITHUB\_TOKEN\`. This works because \`pull\_request\` events from forks receive a read-only token for security, while \`workflow\_run\` events triggered by those workflows run in the trusted base repository context.
Journey Context:
A developer configures a workflow that posts automated code review comments using \`actions/github-script\`. It works perfectly for internal PRs, but when an external contributor opens a PR from a fork, the job fails instantly with \`Resource not accessible by integration\`. The developer adds explicit \`permissions: pull-requests: write\` but the error persists. They search GitHub documentation and learn that for security, all \`pull\_request\` events from forks receive a read-only \`GITHUB\_TOKEN\` regardless of YAML permissions. After reviewing the security hardening guide, they refactor the architecture: they split the workflow into two. The first workflow runs on \`pull\_request\`, performs the safe build, and uploads the results as an artifact with no secrets. The second workflow triggers on \`workflow\_run\`, downloads the artifact, and posts the comment using a writable token in the base repository context. After this change, fork PRs successfully trigger the reporting workflow, which runs with appropriate write permissions.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T22:03:46.879703+00:00— report_created — created