GitHub Actions improvements for fork and pull request workflows

Running Automation on Fork Pull Requests

GitHub Actions has long restricted what can run when a pull request comes in from a fork. In public repositories, workflows triggered by pull_request events execute with a read-only token and no access to secrets, a safeguard against malicious code submitted by unknown contributors. This same restriction applied to private repositories that use a forking model, even though those repositories may be operated by teams that carefully control who can fork and contribute.

To address that, GitHub now offers three new settings — covering enterprises, organizations, and individual repositories — that let private repositories opt into running workflows on fork pull requests. The settings are cumulative: enabling the policy at the enterprise level grants access to all repositories under every organization in that enterprise. This unlocks standard Actions capabilities such as secrets and write tokens for contributors working within a trusted fork network.

The pull_request_target Event

For public repositories, the limitation was less about policy and more about safety. Running arbitrary code from an unknown contributor with broad permissions is a serious security risk. Yet maintainers repeatedly asked for a way to automate common tasks like labeling or commenting on incoming pull requests — actions that require write access and secrets.

The new pull_request_target event answers that need. It fires under the same conditions and carries the same payload as the standard pull_request event, but with a crucial difference: rather than executing the workflow from the merge commit of the pull request, it runs the workflow and code from the base of the pull request. Because the code being executed comes from a trusted source — the repository’s own base branch — Actions grants it a read/write token and access to secrets. This allows maintainers to safely comment on, label, or otherwise interact with pull requests raised from forks. The event can also be combined with the new private repository settings for teams that need the same behavior internally.

Chaining Workflows with workflow_run

Another long-standing request was the ability to chain workflows — to start a new job after another one finishes. The workflow_run event enables exactly that by firing when one or more specified workflows are requested or completed.

Workflows triggered by workflow_run always execute from the repository’s default branch and are granted a read/write token plus secrets. A maintainer might, for instance, set up a CI workflow to build artifacts from a pull request, then have a second workflow triggered by workflow_run analyze those artifacts and post results back to the pull request. The event is also available as a webhook and works for all repository types.

Documentation for the new events and for managing Actions permissions at the repository, organization, and enterprise levels is available on GitHub Docs.