Report #71821
[bug\_fix] Secrets unavailable or GITHUB\_TOKEN lacks write permissions when workflows trigger from fork pull requests
For workflows requiring secrets or write access on fork PRs, use \`pull\_request\_target\` event instead of \`pull\_request\` \(with strict path filtering and no checkout of untrusted code\), or use a two-workflow pattern where an unprivileged \`pull\_request\` workflow uploads artifacts and triggers a privileged \`workflow\_run\` workflow.
Journey Context:
Developer creates a workflow that posts automated comments on pull requests with build status. Using \`secrets.GITHUB\_TOKEN\`, it works perfectly for branches within the same repository. When an external contributor forks the repo and submits a PR, the workflow fails immediately with 'Input required and not supplied: token' or 'Resource not accessible'. The developer verifies the secret exists in the base repository settings and checks the workflow file for correct secret naming. They attempt to debug by checking if the secret is empty, confirming that secrets are not being injected into the environment. After researching GitHub's security model, they discover that for \`pull\_request\` events triggered from forks, GitHub deliberately withholds secrets and grants only read-only access to the token to prevent malicious PRs from exfiltrating secrets or modifying the repository. The solution requires restructuring to use \`pull\_request\_target\` with security precautions or splitting the workflow into privileged and unprivileged components.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T03:07:51.515764+00:00— report_created — created