GitHub blocks pull_request_target by default on 2 December: keep it, switch, or remove

What changed

On 2 November 2026 GitHub published a changelog entry that moves a deadline. From 2 December 2026, GitHub Actions will block the pull_request_target event by default in public repositories. A workflow that uses the event will only run if an Actions event policy explicitly allows it. The block was first announced for 2 November; GitHub pushed it back by one month.

Before the block becomes permanent, GitHub is running temporary brownouts. The first brownout is on 9 November 2026. A second brownout has been reported by third parties for 16 November; treat that date as reported, not confirmed, until GitHub lists it. During a brownout, any blocked workflow attempt fails with an error annotation and does not run. GitHub asks repository owners to review the Actions Insights page before the first brownout so they can see which workflows depend on the event.

Why the change at all: pull_request_target runs in the context of the base branch and carries the base repository's secrets and write token. That is useful for labelling and commenting on pull requests from forks. It is also the mechanism behind a long list of public "pwn request" incidents, where a workflow checked out the fork's code and ran it with those privileges. Blocking the event by default closes that door for repositories that never needed it open.

Which startups are affected

Private repositories are not in scope for this change. If every repository your team ships from is private, nothing breaks on 2 December. You still get a free lesson in where privileged workflows run, and the matrix below applies just as well to you.

You are affected if any of these is true:

• You maintain a public repository (an SDK, a CLI, an open-source tool, a docs site) and it has a workflow with on: pull_request_target.
• You use a marketplace action or a copied workflow that someone else wrote, and you have not read its triggers. Many labeler, "first-time contributor" and preview-deploy workflows use this event.
• You rely on a GitHub App or a bot that comments on pull requests from forks and that bot is implemented as an Actions workflow in your public repository.

The failure mode is quiet. The workflow simply stops running on fork pull requests. Nothing deploys to the wrong place, but a release gate, a licence check or a preview environment might disappear and nobody notices until a contributor asks why their pull request has no status.

Should we keep pull_request_target or switch

This is the decision the page exists to answer, and the honest answer is that it depends on one question: does the workflow need write access or secrets while handling code from a fork?

Our recommendation, in order of preference:

1. Remove it if the workflow only runs tests, lint or a build. Switch to pull_request. Fork pull requests get a read-only token and no secrets, which is exactly what tests need.
2. Split it if the workflow needs to comment, label or publish a preview. Run the untrusted part on pull_request, upload a small artifact, then run a separate privileged job on workflow_run that reads the artifact and never checks out fork code. This is the pattern GitHub's own security guidance has pointed to since 2021.
3. Keep it with an explicit policy only when the first two are not possible, and only if the workflow never checks out github.event.pull_request.head.sha and never runs any script, install step or build tool from the fork. Document the reason in the workflow file so the next engineer does not "fix" it back.

Allowing the event in the policy is not a fix. It is a decision to carry the risk on purpose, and it should be written down like one.

What to check before 9 November

The first brownout is the free test. Do these before it:

1. Open the Actions Insights page for every public repository you own and list the workflows triggered by pull_request_target.
2. Search the repository for the string pull_request_target, including reusable workflows under .github/workflows and any composite actions you vendor.
3. For each hit, write one line: what it does, whether it checks out fork code, and which secrets it reads.
4. Pick a row in the matrix below for each workflow and make the change on a branch.
5. Watch the brownout window on 9 November. A red annotation on a fork pull request tells you exactly which workflow you missed.
6. If you decide to keep the event anywhere, set the Actions event policy before 2 December and record who approved it.

Thirty minutes of reading workflow files now saves a confusing release day in December. If the list of hits is long, or nobody on the team is sure what a workflow does, that is the moment to get a second pair of eyes on CI permissions as a whole, not just this one event.

Our recommendation: Remove pull_request_target where the workflow only tests or builds, split it into pull_request plus a separate privileged job where it must comment or deploy, and keep it behind an explicit policy only as a documented last resort.