Report #75866
[bug\_fix] Secrets are empty or unavailable when pull request is opened from a fork, causing authentication failures in CI
Change the trigger from \`pull\_request\` to \`pull\_request\_target\`, ensuring the workflow file references secrets safely and checks out the base repository code rather than the potentially malicious PR code directly; alternatively, use a \`workflow\_run\` pattern.
Journey Context:
You have a workflow that runs tests and posts coverage reports to an external service using an API key stored in repository secrets \(\`secrets.COVERAGE\_API\_KEY\`\). It works perfectly on pushes to main and on pull requests from branches within the same repository. However, when a community member forks the repository and opens a pull request, the workflow fails immediately with "Error: Input required and not supplied: api-key" or the API client returns 401 Unauthorized. You check the workflow logs and see that the secret value appears empty \(shown as \`\*\*\*\` if you try to echo it, but the receiving action says it's missing\). You verify in Settings > Secrets and variables > Actions that the secret exists and is available to the repository. You re-run the failed job and it fails again. After searching GitHub Community discussions, you learn that this is a security feature: workflows triggered by the \`pull\_request\` event from forks run in an unprivileged context without access to repository secrets, to prevent attackers from modifying the workflow to exfiltrate secrets. The debugging involves checking the \`github.event.pull\_request.head.repo.fork\` property in the workflow context to confirm it's a fork. The fix is to use \`pull\_request\_target\` instead of \`pull\_request\` as the trigger. This runs the workflow in the context of the base repository \(where secrets are available\) using the workflow file from the base branch, not the PR branch. However, you must be careful to checkout the base repository's code \(\`ref: $\{\{ github.event.pull\_request.base.sha \}\}\`\) or explicitly merge the PR code safely, rather than checking out \`github.head\_ref\` directly, to avoid executing untrusted code with access to secrets. This works because pull\_request\_target provides the GITHUB\_TOKEN and secrets of the base repository, while still allowing you to test the PR changes when combined with careful checkout steps.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T09:56:08.599837+00:00— report_created — created