GitHub Blocks pull_request_target by Default on Dec. 2: Public Repos Must Allow the Trigger or Their Agent CI Stops Running

GitHub moved a date on November 2, 2026, and the change matters more than the wording suggests: starting December 2, 2026, GitHub Actions will block pull_request_target events by default in all public repositories, unless an applicable Actions event policy explicitly allows them. The same enforcement had been scheduled for November 2, 2026. Today the rule sits in evaluate mode, so the workflow runs it would block are visible before anything stops, and private and internal repositories are untouched.

The announcement is pull_request_target blocked by default December 2 - GitHub Changelog.

The entry carries a red RETIRED label above its dateline. The announcement underneath it is intact: the page text fetched five minutes before this capture still carries the December 2 date, both November brownout windows and no superseding notice. Read the label as a status flag on the entry, and re-check the page before the first brownout if your plan depends on these dates.

The calendar you can act on

Date (UTC)	What GitHub does
Now until Nov. 8	The default rule runs in evaluate mode. Blocked runs are visible and the workflows still execute
Nov. 9, 16:00 to 18:00	First brownout. Blocked pull_request_target attempts create failed runs with an error annotation, and the workflows do not execute
Nov. 16, 16:00 to 18:00	Second brownout, same behavior. Afterwards the rule returns to evaluate mode and workflows run with warnings
Dec. 2, 2026	Permanent enforcement in public repositories

The scope is narrow and worth reading precisely. The change applies to public repositories on GitHub Free, GitHub Team and GitHub Enterprise Cloud, and explicitly not to GitHub Enterprise Server. A repository that already has an Actions event policy allowing the event is also unaffected, which is the escape hatch most teams will need.

GitHub describes the brownouts as the identification mechanism: the windows “help you identify affected workflows and update your policies before enforcement becomes permanent.” A failed run with an error annotation during a two-hour window is not a broken pipeline. It is the default rule answering a question you can ask it for free.

Why this trigger and not another

pull_request_target is the privileged trigger, and GitHub’s own changelog entry explains the risk: the trigger “runs in the context of the base repository and can access its secrets,” so a workflow that “executes untrusted code from a fork” could “compromise your pipeline or steal secrets.” GitHub’s secure use reference for GitHub Actions is blunter about trigger plus checkout: pull_request_target and workflow_run, “when used with the checkout of an untrusted pull request, expose the repository to security compromises,” because those workflows “are privileged,” “may have repository write access and access to referenced secrets,” and they share the main branch cache with other privileged triggers.

That is why the default is a block rather than a warning. It is also why the rest of that secure use reference matters more now than last month: avoid pull_request_target unless the workflow genuinely needs the privileged context, prefer workflow_run for privilege separation, and never check out untrusted pull-request code inside a privileged workflow.

The two paths, and what each one costs

GitHub’s changelog gives two options. Keep the default rule in place and let pull_request_target be blocked, or explicitly allow the event in an applicable Actions event policy, using workflow file targeting to allow specific workflows rather than the event everywhere.

Find the affected workflows first:

# List the workflow files that declare the privileged trigger.
grep -rn "pull_request_target" .github/workflows/

Then allow only what needs it. An allow is an event policy scoped to workflow paths; the exact field names depend on how your organization applies policies, so treat the next block as the intent rather than a copy-paste payload:

# Illustrative intent: allow pull_request_target for one workflow file.
# Event policies are applied through GitHub's Actions policies API or UI.
name: allow-pr-target-labeler
scope: repository
enforcement: evaluate   # evaluate first, then switch to active
workflow_paths:
  - .github/workflows/pr-labeler.yml
allowed_events:
  - pull_request_target

Two consequences of the allow path deserve a decision before December 2 rather than after.

First, a blocked trigger is a missing step, not a red build. A labeler, a comment bot or the verification step that marks an agent-authored pull request as checked simply stops running. The pull request still looks open to a human and the agent still gets its review, but the machine-readable record is gone, and from December 2 the gap is permanent rather than temporary.

Second, allowing the event reopens the path GitHub is closing, and that is the deal on offer. GitHub’s framing is that the default rule “helps reduce this risk while letting you explicitly allow workflows that depend on the trigger.” A team that allows the event inherits the hardening burden, and the first item on that list is the one the secure use reference already names: a privileged workflow must not check out untrusted code from a pull request fork.

Before the first brownout

Use Insights, as GitHub’s changelog instructs, to see which workflow runs the default rule would block, then decide per workflow: keep it blocked, or allow it in an applicable event policy with workflow file targeting.

If your agent pull request verification runs under pull_request_target, the question to answer before November 9 is not whether to allow the trigger but which of your workflows actually need the privileged context. The GitHub Actions trigger allowlist for agent identities covers the actor and event rules an explicit allow has to fit inside, including which workflow files each agent identity may start. The review bot runner secrets checklist covers what the privileged environment can reach once you allow the event back. The branch protection to rulesets migration guide covers the merge-gate side, so a verification step that stops running shows up as a missing required check rather than a stalled agent.

One other item from the same day is worth a look while you audit your Actions setup. GitHub’s code security risk assessment and secret risk assessment now show whether findings sit in protected or unprotected repositories, which helps you decide where to extend security coverage. It is available in GitHub Enterprise Cloud and GitHub Team, with the secret risk assessment coming to GitHub Enterprise Server 3.24. It does not change the December 2 timeline.

The one-line version

Public repositories get pull_request_target blocked by default on December 2, 2026, with brownouts on November 9 and 16 from 16:00 to 18:00 UTC that produce failed runs with an error annotation on the workflows that would be blocked. Find them in Insights now, allow the event for the specific workflow files that need it, and harden the ones you keep.