Report #74006
[bug\_fix] Resource not accessible by integration when creating PR or issue using GITHUB\_TOKEN
Explicitly declare the required permissions using the \`permissions\` key at the workflow or job level, e.g., \`permissions: contents: write pull-requests: write\`. The root cause is that GitHub changed the default \`GITHUB\_TOKEN\` permissions to read-only for new repositories and organizations, and workflows triggered by forks never receive write access. Without explicit permissions, the token lacks the scopes required to modify repository contents or open pull requests.
Journey Context:
The workflow suddenly starts failing with "Resource not accessible by integration" when attempting to create a pull request using \`gh pr create\` or the REST API, despite the identical code working in other repositories. You verify the repository settings and see that "Read and write permissions" is enabled for workflows, yet the error persists. You try using a Personal Access Token \(PAT\) with \`repo\` scope instead of \`secrets.GITHUB\_TOKEN\`, and the step succeeds immediately, confirming the issue is permission-scoping rather than API usage. After examining the workflow logs, you notice the token permissions summary only lists \`contents: read\` and \`metadata: read\`. Searching the GitHub documentation for "automatic token authentication," you discover that repositories now default to restricted permissions, and that the \`permissions\` key in the workflow YAML must explicitly grant \`write\` access for specific scopes. You add \`permissions: pull-requests: write contents: write\` to the job definition, remove the PAT, and the workflow successfully creates pull requests using the default GITHUB\_TOKEN.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T06:48:51.891521+00:00— report_created — created