Lesstep
GitHub Actions · pull_request_target · Checked November 5, 2026

"Event 'pull_request_target' is not allowed to trigger Actions workflows": GitHub's default policy for public repositories, the November 9 and 16 brownouts, and December 2, 2026

GitHub has added a default Actions policy that blocks workflows triggered by pull_request_target in public repositories. So far it runs in evaluate mode, which only adds a warning to the run. GitHub will enforce it from December 2, 2026, and before that during two brownouts, on November 9 and November 16, each from 16:00 to 18:00 UTC: affected runs then fail with an error annotation, and the workflow does not run. Private and internal repositories and GitHub Enterprise Server are not affected. To keep a workflow on this trigger, allow it with an Actions event policy of your own; otherwise move it to pull_request, or let it stop.

What it looks like

Now, in evaluate mode, a run that the policy would block gets a warning annotation like this one (flutter #193185, September 2026; GitHub has since moved the date to December 2):

Workflow execution policy warning (evaluate mode): .github/workflows/revert.yml#L1
On November 2, 2026, GitHub will restrict `pull_request_target` on public repositories by default. To continue allowing the event trigger, configure an Actions policy. Learn more: https://gh.io/securely-using-pull_request_target#default-policy-for-pull_request_target

When a policy blocks an event, GitHub's documentation says the run fails with an error of this form. A repository whose own policy refuses pull_request_target already gets it (metadatastician/standards #1102):

Event 'pull_request_target' is not allowed to trigger Actions workflows. Workflow file: '.github/workflows/security-gate-pr-target.yml'.

GitHub's changelog says that runs blocked during the brownouts fail with an error annotation, and does not give its text.

The dates

Which workflows it hits

GitHub adds the default policy only where no applicable Actions event policy exists, and it blocks the event itself, whatever the workflow does with it. To list the workflows of a repository:

grep -rln 'pull_request_target' .github/workflows

Across the public repositories of an organization, search GitHub's code for org:ORG path:.github/workflows pull_request_target. The runs the policy would block are also listed in Policy insights, under Settings, Actions, Policies of the repository or organization. GitHub code search finds about 89,000 workflow files with pull_request_target (November 5, 2026). Labeling and triage workflows are common among them: the README of actions/labeler starts its example with on: pull_request_target.

Option 1: move the workflow to pull_request

GitHub's documentation says to use pull_request if the workflow does not need more access to secrets. A workflow that builds or tests the pull request belongs there anyway: running the fork's code under pull_request_target gives it the repository's secrets.

 on:
-  pull_request_target:
+  pull_request:

On pull_request, runs for pull requests from forks get a read-only GITHUB_TOKEN and no secrets, so a step that labels or comments fails with "Resource not accessible by integration". For a comment, GitHub's documentation shows two workflows: the pull_request one uploads the pull request number as an artifact, and a workflow_run workflow reads it and comments.

Option 2: keep the trigger with an event policy

In the repository or organization, open Settings, and under Actions in the sidebar, Policies. Create a policy with a name and the enforcement status Active (Evaluate is for GitHub Enterprise Cloud only), target the workflow files that need the trigger, and under Restrict events allow pull_request_target.

An event rule lists the events that can trigger the workflows it targets, so list every event in their on:, not only pull_request_target: a workflow that also has workflow_dispatch or schedule needs those too.

The same with the REST API, as a repository administrator. The body follows GitHub's REST reference for creating a repository Actions policy:

gh api -X POST repos/OWNER/REPO/actions/policies \
  -H "X-GitHub-Api-Version: 2026-03-10" --input - <<'EOF'
{
  "name": "Allow pull_request_target for the labeler",
  "enforcement": "active",
  "conditions": {"workflow_path": {"include": [".github/workflows/labeler.yml"], "exclude": []}},
  "rules": [{"type": "restrict_action_events", "parameters": {"allowed_events": ["pull_request_target"]}}]
}
EOF

GitHub warns to allow the event only when it is necessary, and never to check out, build or run code from an untrusted pull request with access to secrets or a write token. What that means for checks on pull requests from forks: checks failing or waiting on pull requests from forks.

Telling it apart

See failed jobs from IntelliJ IDEA

Pipeline Inbox for GitHub Actions Workflows, a plugin by Lesstep for JetBrains IDEs 2024.1 or later, lists the runs of all your repositories in an IDE tool window, with their jobs and steps, so the runs a brownout failed stand out, and your current branch's runs are in the status bar. Reading is free; re-running failed jobs, cancelling, running workflows and reviewing deployments are Pro (US$1.50 a month, with a 30-day trial).

Get it on JetBrains Marketplace

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

More: checks on pull requests from forks · "Resource not accessible by integration" · GitHub Actions plugins for IntelliJ IDEA compared · 日本語