GitHub · Pull requests · Forks · Checked October 27, 2026

GitHub: checks fail on a pull request from a fork

With the exception of GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository, and the GITHUB_TOKEN has read-only permissions in pull requests from forked repositories (GitHub's events that trigger workflows, checked October 27, 2026). The pull_request event runs the workflow file from the merge commit of the pull request, and for a pull request from a fork that commit is controlled by someone without write access to the base repository, so a step that needs a secret or writes to the repository fails there (GitHub's securely using pull_request_target).

pull request from a fork     pull_request runs from the merge commit
GITHUB_TOKEN                 read-only
other secrets                not passed
private repository           Fork pull request workflows settings
pull_request_target          default branch code, secrets, write token

Why it fails

The secret is empty: a login to a registry or a deploy that reads a secret gets nothing, because only GITHUB_TOKEN is passed.
The write is refused: a step that comments, labels or pushes with GITHUB_TOKEN has a read-only token. The same limits apply to pull_request_review and pull_request_review_comment, and to pull requests Dependabot opened (see Dependabot pull request checks).
The checks come from the base repository: GitHub sends the pull request events of a pull request from a fork to the base repository, and none occur on the fork (GitHub's pull request events for forked repositories). Workflows do not run in a fork by default; Actions has to be turned on in the fork's Actions tab.
Nothing ran yet: for a first-time contributor to a public repository, a maintainer may need to approve the runs first (see workflow-created pull requests).

Private repositories: Fork pull request workflows

For a pull request from a fork to a private repository, workflows run only when they are turned on. Under Settings, Actions, General, Fork pull request workflows, the policies are (GitHub's enabling workflows for forks of private repositories):

Run workflows from fork pull requests: runs them with a read-only GITHUB_TOKEN and no access to secrets.
Send write tokens to workflows from pull requests: gives pull requests from forks a GITHUB_TOKEN with write permission.
Send secrets to workflows from pull requests: makes all secrets available to the pull request.
Require approval for fork pull request workflows: runs on pull requests from collaborators without write permission wait for approval from someone with write permission.

The policies can be set for an organization or a repository; a policy turned off for the organization cannot be turned on for a repository.

What to do

Keep building and testing on pull_request: GitHub says to use pull_request if additional secret access is not needed, and to separate handling of the pull request code from accessing secrets in more complex workflows (GitHub's deciding whether to use pull_request_target).
Label or comment with pull_request_target: it runs in the context of the default branch of the base repository and gets its GITHUB_TOKEN and secrets, which lets a workflow label or comment on pull requests from forks. GitHub says to avoid it if you need to build or run code from the pull request (GitHub's pull_request_target).
Do not run the fork's code with secrets: checking out the pull request head under pull_request_target and then building or testing it runs the fork's code with the secrets. actions/checkout checks out pull request head refs from forks there only with allow-unsafe-pr-checkout: true, which GitHub says to set only after confirming the checked-out code is never executed (GitHub's opting out of built-in protections).
Public repositories: where no applicable Actions event policy exists, GitHub adds a default policy that blocks workflows triggered by pull_request_target. It runs in evaluate mode for now, so runs continue, and GitHub says it will enforce it on December 2, 2026 for affected repositories. To keep the event, create an event policy that allows it (GitHub's default policy for pull_request_target).
A cache save warns: workflows triggered by pull_request_target can restore caches of the default branch but cannot save them; the save fails with a warning in the log and the job continues. Save the cache from a trusted trigger such as push (GitHub's hardening a pull_request_target workflow).

GitHub pull requests in IntelliJ IDEA

Pull Request Inbox for GitHub, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, shows a pull request's reviews, checks and conversations next to the diff, and merges it with the methods the target branch allows. It lists the checks GitHub reports on the head commit, each with a link to its run, so a failed job on a pull request from a fork opens on GitHub with its log. It checks out a pull request from a fork by fetching the head GitHub keeps for every pull request into a branch named after the pull request, and after a merge it does not offer to delete the fork's branch. It does not change workflows, secrets or repository settings. The review inbox, diffs and conversations are free; approving, commenting, resolving and merging are Pro (US$1.50 a month, with a 30-day trial).

GitHub is a trademark of GitHub, Inc.; IntelliJ IDEA is a trademark of JetBrains s.r.o. This page is not affiliated with or endorsed by GitHub, Inc. or JetBrains.