GitHub Set a November 2 Deadline for pull_request_target. The Breaking Change Landed in July.

On 17 September 2026 GitHub moved workflow execution protections for Actions to general availability: allowlists that control who may trigger a workflow and which events are permitted to start one. Shipped alongside it is a default event policy that blocks pull_request_target in public repositories. It runs in evaluate mode today and GitHub enforces it on 2 November 2026.

That November date is the one going into calendars. It is not the change that has already broken builds.

What went GA, and where it stops

The feature gives you two rule types, scoped to whole accounts or to individual workflow paths, plus policy insights and a REST API. The docs source answers what the changelog leaves open.

Availability has edges the changelog did not name. The page for controlling workflow execution declares its product scope as all public repositories, plus private repositories on Team or Enterprise — a private repository on a free account is outside the feature entirely. The docs version gate gives the protections to GitHub Enterprise Server from 3.23. The gate for the default pull_request_target policy lists only the dotcom products, with no Enterprise Server entry at all, so the November deadline is a dotcom event.

The REST surface is narrower too. GitHub's published API description carries POST /repos/{owner}/{repo}/actions/policies and POST /orgs/{org}/actions/policies, and no equivalent path under /enterprises/, though the changelog describes management at the enterprise level. The enforcement field takes disabled, active or evaluate, and the schema notes that evaluate requires GitHub Enterprise.

The event rule is an allowlist, not a block list

This is the part worth reading the schema for. The restrict_action_events rule takes an allowed_events array drawn from a 36-value enumeration — push, pull_request, pull_request_target, schedule, workflow_dispatch, workflow_run, merge_group and twenty-nine others.

So the obvious reaction to the deadline, which is to write a policy that permits pull_request_target so the default one stops applying, turns off every other trigger on the workflows that policy targets. Listing one event does not add an exception. It declares the complete set.

The actor rule has the same shape: allowed_actors holds {id, type} pairs, with type drawn from eight values including Bot, App, IntegrationInstallation and RepositoryRole. The docs are explicit that if one of your workflows is triggered by an identity such as dependabot[bot], that identity has to be listed. Anyone wiring a coding agent into CI should read that sentence twice. The permissions work we argue is most of the real integration job, in our note on the PoC-to-production gap, now includes a CI admission list.

The change that already broke builds

actions/checkout v7 shipped on 18 June 2026 refusing by default to check out fork pull request code under pull_request_target and workflow_run. Enforcement of the backport to older majors was scheduled for 16 July and moved to 20 July. The v4.4.0 release notes mark it BREAKING.

Every moving major tag from v2 to v7 now serves an action.yml carrying the new allow-unsafe-pr-checkout input. v1 did not get the change. Pins to a SHA, a minor or a patch were untouched. If your workflows say actions/checkout@v4, this landed in your pipeline two months ago.

What the guard actually checks

The enforcement lives in one helper file, and it is pattern matching, not a boundary. It returns silently unless the event is pull_request_target or workflow_run; for workflow_run, only when the triggering event name starts with pull_request. It then requires the head repository id to differ from the base repository id. Only then does it test three things: whether the resolved repository equals the fork's full name, whether the ref matches refs/pull/<number>/head or /merge, or whether the resolved commit is one of the pull request head SHAs carried in the payload. No match, no error.

Fetching the fork's code any other way — git fetch against the fork remote, gh pr checkout, downloading an artifact a fork's run produced — passes straight through. One detail from the source: for a workflow_run triggered by pull_request_target, the helper skips workflow_run.head_sha entirely, under a comment noting that value is the base default branch SHA rather than the pull request head.

Two gates, and clearing one does nothing for the other

tinygrad's line-count workflow is a worked example. It triggers on pull_request_target, checks out the fork by full name and head SHA, sets allow-unsafe-pr-checkout: true and persist-credentials: false, and carries a comment stating the code is only counted, never executed. That is the opt-in used the way the docs describe it, and it clears the July gate.

It does nothing for November. The default policy's carve-outs are three: private and internal repositories, repositories that already have an applicable event policy configured, and the fact that the policy is presently in evaluate mode. Checkout inputs are not on that list.

Scale, from GitHub code search on 18 September 2026, restricted to indexed public default branches: 61,696 files under .github/workflows match pull_request_target:, while 1,716 match allow-unsafe-pr-checkout and 1,350 match it set to true. Those are file counts, not repository counts, and the opt-in exists only because of the July change. So roughly fourteen hundred public workflow files have been edited for July, against a November rule scoped at every public repository without an event policy.

The decision to make before 2 November

Inventory first: grep -rln pull_request_target .github/workflows per repository, or across an organisation, gh api -X GET search/code -f q='org:ACME pull_request_target path:.github/workflows' --jq '.total_count'.

For each hit, make one decision and record it: move the workflow to pull_request, or keep the event and write an explicit event policy for it. Writing the policy is the work this quarter, because the default rule steps aside only for repositories that have an applicable one. When you write it, scope it with a workflow_path include pattern so the blast radius is one file, and enumerate every event those workflows actually use.

Then one threshold. Any workflow carrying allow-unsafe-pr-checkout: true is a workflow where someone decided untrusted code would land in the workspace. Those get the hardening the docs list — least-privilege GITHUB_TOKEN, awareness that the cache is read-only from that trigger, isolated and ephemeral runners, CodeQL for Actions — and a comment naming what stops the checked-out code from running.

What would make this wrong

If your repositories are all private or internal, November is not your problem, and if you pin every action to a SHA, July was not either. The narrow claim here is that the two gates are independent: it would be false if the default policy exempted repositories that had adopted the checkout flag. The doc lists three carve-outs, and that is not one of them.