Report #50320
[bug\_fix] Secrets and write token unavailable in pull requests from forks
Use the \`workflow\_run\` event to trigger a secondary workflow that runs in the base repository context with full secret access, or use \`pull\_request\_target\` with strict path filtering and checkout of the base ref only, avoiding execution of untrusted code from the PR.
Journey Context:
An external contributor opens a pull request from their fork to your open-source project. The workflow runs immediately, but steps that require a secret \(like an API key for a testing service\) fail with "Error: Input required and not supplied", or steps that post PR comments receive a 403. You verify the secret exists in the base repository settings. You check the workflow event and see it triggers on \`pull\_request\`. You research and discover that GitHub explicitly withholds secrets and write permissions from workflows triggered by the \`pull\_request\` event when the PR originates from a fork, to prevent malicious exfiltration. You consider switching the trigger to \`pull\_request\_target\`, which runs in the base context, but realize this checks out the base repository code by default, not the PR code, and introduces severe security risks if running untrusted code. You eventually implement a two-workflow pattern: the first workflow runs on \`pull\_request\` with no secrets, performing untrusted code execution and uploading test results as artifacts. A second workflow triggers on \`workflow\_run\` when the first completes, running in the trusted base repository context with full secret access to process the artifacts and post results back to the PR.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T14:56:39.908464+00:00— report_created — created