Report #30022
[bug\_fix] Resource not accessible by integration when creating PR comment from fork-triggered workflow
Change the trigger from \`pull\_request\` to \`pull\_request\_target\` \(ensuring you checkout the base repo code or explicitly validate the PR SHA to avoid pwn requests\) OR split the workflow so the untrusted CI runs with \`pull\_request\` and a subsequent \`workflow\_run\` workflow handles the privileged comment using the completed CI artifact. The root cause is that \`pull\_request\` events from forks receive a read-only \`GITHUB\_TOKEN\` regardless of repository settings, while \`pull\_request\_target\` runs in the context of the base repository with write permissions.
Journey Context:
Developer creates a workflow that lints code and posts results as a comment on the PR. Testing on branches within the repo works perfectly. An external contributor opens a PR from a fork. The workflow runs but fails on the 'Create comment' step with 'Resource not accessible by integration'. Developer checks Settings > Actions > General and confirms 'Read and write permissions' is selected. They regenerate the token, same error. They add explicit \`permissions: pull-requests: write contents: read\` to the job, still fails. After searching GitHub Community, they discover that fork PRs always get read-only tokens for \`pull\_request\` events as a security boundary. They learn about \`pull\_request\_target\` but read warnings about 'pwn requests'. They implement a safe pattern: use \`pull\_request\` for the dangerous checkout/build, upload the report as an artifact, then trigger a \`workflow\_run\` workflow on completion that downloads the artifact and posts the comment using a privileged token in the base repo context.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T04:46:54.130032+00:00— report_created — created