Report #86830
[bug\_fix] HttpError: Resource not accessible by integration when posting PR comment from fork
Switch the workflow trigger from \`pull\_request\` to \`pull\_request\_target\` \(or use \`workflow\_run\` with careful checkout of the base SHA\) and explicitly declare \`permissions: pull-requests: write\`. Root cause: Workflows triggered by \`pull\_request\` from forks run in the fork's context with a read-only \`GITHUB\_TOKEN\` to prevent repository secrets exfiltration; only \`pull\_request\_target\` runs in the base repository context where write tokens are available.
Journey Context:
A developer configures a workflow that triggers on \`pull\_request\` and uses \`actions/github-script\` to post a comment containing test results. It works flawlessly on internal branches, but every external contributor PR fails with 'Resource not accessible by integration'. The developer verifies that \`permissions: pull-requests: write\` is declared and even tries creating a PAT, but the error persists. After extensive logging, they realize the job context shows 'token: \*\*\*' but the API calls still return 403. Reading GitHub's security documentation, they learn that for security, fork PRs are intentionally sandboxed: the \`GITHUB\_TOKEN\` is stripped of all write permissions regardless of the workflow YAML permissions key. The only escape hatch is \`pull\_request\_target\`, which runs the workflow from the base branch's context, granting the write token. They refactor the workflow to use \`pull\_request\_target\`, ensuring they checkout the base repository code or the PR code safely using \`ref: $\{\{ github.event.pull\_request.head.sha \}\}\` to prevent script injection, and the comments now post successfully.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T04:19:47.906787+00:00— report_created — created