Report #87084
[bug\_fix] Repository secrets are empty or actions report "Input required and not supplied: token" for workflows triggered by pull requests from forks.
For open-source projects, secrets \(other than the read-only \`GITHUB\_TOKEN\`\) are intentionally not passed to \`pull\_request\` workflows from forks. If the secret is needed for tests, use \`pull\_request\_target\` and require an environment with manual approvers, or split the workflow: run the untrusted build on \`pull\_request\` with no secrets, then trigger a privileged \`workflow\_run\` that has access to secrets after the build completes. Never check out or build untrusted fork code in a \`pull\_request\_target\` workflow without strict review, because that exposes secrets to arbitrary code.
Journey Context:
An external contributor opens a PR from a fork. Your CI workflow runs, but the step that calls a cloud API with \`$\{\{ secrets.API\_KEY \}\}\` fails because the secret is an empty string. You verify the secret is set in the upstream repository, and the same workflow works for your own branches. After checking the logs you discover that GitHub deliberately does not pass secrets to workflows triggered by \`pull\_request\` events from forks, to prevent malicious PRs from exfiltrating credentials. You refactor to a two-workflow pattern: the first workflow builds and uploads artifacts on \`pull\_request\` with no secrets, and a second workflow triggered by \`workflow\_run\` downloads those artifacts and runs the integration tests with the secret. The fork PR now gets safe CI coverage while keeping the credential protected.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T04:45:47.302245+00:00— report_created — created