Report #88694
[bug\_fix] Resource not accessible by integration \(403\) when creating a release or pushing to a protected branch using the default GITHUB\_TOKEN
Add an explicit \`permissions\` block granting \`contents: write\` \(or the specific required scope\) at the workflow or job level. This elevates the automatically generated GITHUB\_TOKEN's access without resorting to a long-lived Personal Access Token \(PAT\).
Journey Context:
A developer configures a workflow to automatically create a GitHub Release when a tag is pushed, using \`softprops/action-gh-release\`. On the first push, the job fails with a 403 error "Resource not accessible by integration" despite the workflow appearing to have a \`GITHUB\_TOKEN\` automatically provided. The developer initially assumes the token is broken and spends time generating a fine-grained Personal Access Token, storing it in Secrets, and switching the workflow to use \`token: $\{\{ secrets.MY\_PAT \}\}\`. This works, but feels insecure and requires manual token rotation. After further research, the developer discovers that GitHub Actions workflows now default to restrictive permissions for the \`GITHUB\_TOKEN\`. The "aha" moment comes when reading the documentation: the token's permissions can be explicitly declared in the YAML using the \`permissions\` key. By adding \`permissions: contents: write\` to the job, the default token suddenly has the required scope, the PAT can be deleted, and the workflow works securely without storing long-lived credentials.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T07:27:24.447200+00:00— report_created — created