GitHub Actions: "Event 'pull_request_target' is not allowed to trigger Actions workflows"

Event 'pull_request_target' is not allowed to trigger Actions workflows. Workflow file: '.github/workflows/labeler.yml'.
# expected annotation on a "Startup failure" run in a public repository during the 9 and 16 November brownouts and from 2 December 2026 (GitHub hasn't published the text; this is the message we captured for a blocked event, with the event name changed)

Short answer: From 2 December 2026 GitHub Actions blocks pull_request_target runs in public repositories by default, unless an Actions event policy allows the event. Brownouts on 9 and 16 November (16:00 to 18:00 UTC) block it for two hours each. Move workflows that build or test pull request code to pull_request. For the ones that must keep pull_request_target (labelers, comment bots), add an event policy scoped to those workflow files that allows pull_request_target and every other event they use.

Many workflows, or not sure which ones are safe to allow? Send a GitHub invite and I send a pull request plus the exact event policy within 48 hours: $49 per repository, card, no account. Still blocked after you apply it: full refund. The free steps are below.

Checked on 4 November 2026 against GitHub's changelog and docs, and our own test in a public repository.

Why it happens

GitHub's changelog of 2 November 2026: pull_request_target runs in the base repository's context with its secrets, so a workflow that runs code from a fork can leak them. A default rule now blocks the event in public repositories on GitHub Free, Team and Enterprise Cloud that have no applicable Actions event policy. Private and internal repositories and GitHub Enterprise Server are not affected. The rule runs in evaluate mode until enforcement on 2 December (moved from 2 November). During the two brownouts, blocked runs fail with an error annotation and the workflow doesn't run; after each window the rule goes back to evaluate mode. The trap: an event policy is an allowlist. If it names only pull_request_target, every other event of the workflows it targets is blocked. How we verified it (a dated vendor change): on 4 November 2026, in a public test repository on GitHub Free, we created a repository event policy through the REST API that allowed only pull_request_target for one workflow. Its next push run ended in Startup failure with the annotation "Event 'push' is not allowed to trigger Actions workflows". After we added push and workflow_dispatch to the policy, both ran. Evaluate mode was refused on GitHub Free (422 Validation Failed), as the docs say (Enterprise Cloud only). We haven't seen a brownout run yet, so the pull_request_target wording above is that message with the event name changed.

You may also see

Event 'push' is not allowed to trigger Actions workflows. Workflow file: '.github/workflows/ci.yml'.
# what we captured on 4 November 2026: an event policy that allowed only pull_request_target blocked the workflow's push runs too

Startup failure
# the run's status: no job starts and there is no log

Fix

Find the workflows that use it. From the repository root:

grep -rlE "^[^#]*pull_request_target" .github/workflows/

To see every event each of them uses (you need the full list in step 3), run this script (Python 3 with PyYAML):

# prt_events.py: which workflows use pull_request_target, and every event each one needs in the policy
# usage, from the repository root: python3 prt_events.py   (needs PyYAML: pip install pyyaml)
import glob, yaml
for path in sorted(glob.glob(".github/workflows/*.y*ml")):
    doc = yaml.safe_load(open(path, encoding="utf-8")) or {}
    on = doc.get("on", doc.get(True))  # YAML 1.1 reads a bare `on:` key as True
    events = [on] if isinstance(on, str) else list(on or [])
    if "pull_request_target" in events:
        print(f"{path}: {', '.join(events)}")

For a whole organization, search GitHub code for org:YOUR-ORG path:.github/workflows pull_request_target. GitHub's changelog also points to Settings → Actions → Policies → Policy insights, which lists the runs the default rule would block.

Sort them. A workflow that checks out and builds or tests the pull request's code should move to pull_request, which is also GitHub's advice: it runs the pull request's own code with a read-only token and, for forks, without secrets.
```
# before
on:
  pull_request_target:

# after: runs the pull request's own code with a read-only token and, for forks, no secrets
on:
  pull_request:
```
A workflow that only labels, comments, assigns or greets, and never runs the pull request's code, can't do that on pull_request for forks (the token is read-only). Keep it on pull_request_target and allow it in step 3.
Allow the ones you keep with an event policy scoped to those files. In the repository (or organization): Settings → Actions → Policies, new policy, enforcement Active, target the workflow files, and under Restrict events allow pull_request_target plus every other event those files use (from step 1: workflow_dispatch, issues, schedule...). Leave one out and its runs fail. The same policy through the REST API, as a repository admin (we created one like it on 4 November 2026; replace OWNER/REPO and the file and events with yours):
```
cat > policy.json <<'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", "workflow_dispatch"]}}]
}
EOF
curl -X POST -H "Authorization: Bearer $GITHUB_TOKEN" -H "Accept: application/vnd.github+json" \
  -H "X-GitHub-Api-Version: 2026-03-10" --data @policy.json \
  https://api.github.com/repos/OWNER/REPO/actions/policies
```
The policy only applies to the files in workflow_path; your other workflows keep the default rule.
Test before 9 November: run the allowed workflow by hand (Actions → the workflow → Run workflow, if it has workflow_dispatch) and open a test pull request. A run that ends in Startup failure means the policy is missing an event: open the run, read the annotation, add that event.
If a run was blocked during a brownout, it never executed, so nothing ran. Trigger it again after the window: push a new commit to the pull request, or close and reopen it (reopened is one of pull_request_target's default activity types).

Many workflows, or not sure which ones are safe to keep on pull_request_target? I go through every workflow in the repository, move the ones that can run on pull_request, and write the event policy for the rest with every event they use (one command or a few clicks for you to apply). You get a pull request with a list of every change.

Get it fixed: $49

Pay by card, no account needed. Pull request within 48 hours; workflows still blocked after you merge and apply the policy, full refund.

How it works: 1. Pay on Gumroad; the checkout asks for the repository. 2. Invite my GitHub user, Donrulezz, to that repository only (private is fine), or email a zip with the failing log to hello@deadlinefix.com. 3. You get a pull request with a list of every change; you review, merge and deploy. I never ask for cloud passwords or production keys.

Who does the work: me, Ashish, the owner of this site, based in India. My public code and tools are on GitHub: github.com/Donrulezz.

Watch out

Don't allow pull_request_target for a workflow that builds or runs the pull request's code: that is the hole the default rule closes. Since v7, actions/checkout refuses to check out fork pull request code there unless you set allow-unsafe-pr-checkout: true; GitHub says to set it only when the checked-out code is never executed.
Evaluate mode (watch without blocking) is GitHub Enterprise Cloud only for your own policies. On GitHub Free and Team a new policy is Active at once, so list every event before you save it.
Splitting a workflow into pull_request plus workflow_run? GitHub's docs say to treat artifacts uploaded by the first workflow as untrusted, because a fork can write them.
Organization policies can also target repositories by name, ID or custom property (REST API docs). We tested a repository policy only.
Private and internal repositories and GitHub Enterprise Server are not affected by the default rule.

Sources

Did this fix it?

Other errors breaking soon

All "breaking soon" fixes