A workflow_run chain keeps the fork's code out of the job that holds the secrets

actions/checkout decides whose code the rest of the run executes. It authenticates with GITHUB_TOKEN, fetches the repository at a commit or ref, and places the files into $GITHUB_WORKSPACE so later steps can read them ^[1]. Under the pull_request trigger, the default is the pull request's head commit ^[2]. On a fork, that head commit belongs to someone with no permissions in your repository, so GitHub hands the job a read-only token and withholds secrets ^[3]. Jobs that need a secret fail there, and they fail on purpose ^[4].

pull_request_target, added in 2021, inverts both halves. The token becomes read/write on forked pull requests, and the context defaults to the base repository ^[5]. That default is what makes automated labels, comments and project board updates workable ^[6]. Secret-dependent workflows do run. They run against the base tree, and the dev.to article says this misleads unaware developers with false test results ^[7].

To aim that job at the proposed change, the fork's head has to be checked out explicitly ^[8]. Here the article's text and its own snippet ask for different things: the prose says the head SHA must be set, and the snippet passes `ref: ${{ github.event.pull_request.head.ref }}` ^[8][9]. One names a commit, the other names a branch. The same article lists exploiting race conditions among the ways automated processing of fork pull requests goes wrong ^[10]. I would pin the SHA the prescan actually examined, and I would keep build steps out of that job entirely. The article puts the boundary in the same place: the primary use case for pull_request_target is non-invasive maintainer tasks on forks, not running or building untrusted code ^[11].

"Any automated processing of PRs from an external fork is potentially dangerous and such PRs should be treated like untrusted input," Jaroslav Lobačevski of GitHub wrote in Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests ^[16].

The alternative is two files.

1. A prescan workflow triggered by pull_request. The fork's code is in context, and no secrets are available ^[13]. 2. On successful completion, workflow_run starts the second workflow. GitHub's documentation says "The workflow started by the workflow_run event is able to access secrets and write tokens, even if the previous workflow was not" ^[14].

The prescan decides whether the secrets-bearing job ever starts, so its failure conditions are what prevent exposure. The article's example is an author check written with `if` comparisons against the head repository's full name ^[15]. workflow_run was also introduced in 2021 ^[12], so both events have been available for the same length of time ^[18].

The article states there is no foolproof way to allow secrets access on untrusted forked pull requests, and points readers to a repository cataloguing what can go wrong ^[10][17]. The chain's guarantee is narrower than safety: the job that reads the fork's tree holds no secrets, and the job holding secrets starts only after the prescan passes ^[13].