Report #103818
[bug\_fix] GitHub Actions workflow fails with 'Resource not accessible by integration' or 'Permission denied' when the workflow tries to create an issue, comment on a PR, push a commit, upload an artifact, or write security events using GITHUB\_TOKEN.
Add an explicit \`permissions\` block at the workflow or job level granting only the scopes that step actually needs. For example, use \`permissions: contents: write\` for pushing commits, \`issues: write\` for creating issues, \`pull-requests: write\` for PR comments, \`packages: write\` for publishing packages, and \`actions: write\` for caching artifacts. Repos created after February 2023 \(or repos where an admin changed the default\) inherit a read-only GITHUB\_TOKEN when no \`permissions\` block is present, so any write operation fails. Set a least-privilege workflow-level default and override at the job level only when a job needs more.
Journey Context:
The workflow worked fine in an older repository, but after forking it into a new org it started failing every time it tried to open a GitHub issue. The logs showed a 403 'Resource not accessible by integration'. The developer first suspected a bad secret, then tried passing \`secrets.GITHUB\_TOKEN\` explicitly, then checked branch protection, then even generated a PAT. After comparing the two repos, they noticed the new repo's Settings > Actions > General had 'Workflow permissions' set to 'Read repository contents and packages permissions'. Older repos often default to 'Read and write permissions'. The real fix was not using a PAT but declaring the needed scope in YAML. Once \`permissions: issues: write\` was added at the job level, the issue-creation step succeeded. The root cause is that GitHub changed the default token posture, so workflows that relied on the old broad default now fail unless they explicitly request the right scope.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-13T04:45:32.474780+00:00— report_created — created