Does the pull_request_target block affect private repositories?

No. GitHub's November 2, 2026 changelog says private and internal repositories aren't affected. The default rule covers public repositories on GitHub Free, Team and Enterprise Cloud. GitHub Enterprise Server is not included.

What happens during the November 9 and November 16 brownouts?

From 16:00 to 18:00 UTC on each day, pull_request_target runs the default rule would block fail with an error annotation and don't execute. After each window the rule goes back to evaluate mode and runs continue with warnings.

Will my AI code review bot stop working on December 2?

If it runs as a GitHub Actions workflow triggered by pull_request_target in a public repository, and no Actions event policy allows that trigger, yes. Either change the trigger to pull_request or allow pull_request_target for that one workflow file.

GitHub Blocks pull_request_target Dec 2: AI Review Bots

Yes, GitHub is blocking pull_request_target: from Wednesday, December 2, 2026, GitHub Actions refuses to run workflows on that trigger in any public repository unless an Actions event policy explicitly allows it. Before that, it switches the block on for two hours on Monday, November 9 and Monday, November 16, 16:00 to 18:00 UTC (11:00 to 13:00 in New York, 16:00 in London). Private and internal repositories are not affected. The small teams we'd expect to get caught are the ones running an AI reviewer on a public repo, because PR-Agent's setup guide tells you to use exactly this trigger so the bot works on pull requests from forks.

Event date: November 2, 2026 (GitHub Changelog, "pull_request_target blocked by default December 2"). First report: the same changelog post; GitHub had moved the date from November 2 to December 2 in an October 21 editor's note on its September 17 announcement.

Who has to act before November 9

Anyone who owns a public repository on GitHub Free, Team or Enterprise Cloud with a workflow whose on: block lists pull_request_target. GitHub Enterprise Server is out of scope. Setting the policy takes a repository administrator, organization owner or enterprise owner, per GitHub's policy docs; a contributor with write access can't do it.

GitHub's docs add a condition we couldn't fully decode: on December 2 it will enforce the rule "for affected repositories that were using the default pull_request_target policy before general availability", meaning before September 17, 2026. A repo created since then is likely covered too, but GitHub doesn't say so in either post, so treat it as covered.

What GitHub changed on November 2, and what it already changed in June and July

The rule itself isn't new. GitHub made workflow execution protections generally available on September 17, 2026, added a default rule that blocks pull_request_target in public repos, and ran it in evaluate mode: runs go through, and the Policy insights page records the ones that would have been blocked. The November 2 post adds the dates and the brownouts. During a brownout, blocked runs fail "with an error annotation; the workflows won't execute." Afterwards the rule goes back to evaluate mode.

GitHub Changelog of November 2, 2026 showing the brownout schedule for pull_request_target: November 9 and November 16, 2026, 16:00 to 18:00 UTC

Screenshot: GitHub Changelog, "pull_request_target blocked by default December 2", November 2, 2026. Captured November 4, 2026.

A second change landed earlier and got less attention. On June 18, 2026, actions/checkout v7 shipped and, per GitHub's changelog, "refuses common pwn request patterns by default": it "now refuses to check out fork pull request code by default" when the workflow runs on pull_request_target or workflow_run. On July 20, 2026 GitHub backported it as breaking releases v4.4.0, v5.1.0 and v6.1.0, plus v3.7.0 and v2.8.0; v1 doesn't get it, and same-repository pull requests aren't affected. To get the old behaviour back you set allow-unsafe-pr-checkout: true, which GitHub's docs say is "intentionally named to be easy to spot in code review". The floating @v4, @v6 and @v7 tags point at v4.4.0, v6.1.0 and v7.0.1 (we checked the tag commits on November 4), so a workflow that checks out a fork pull request's head through @v7 has been refused since June 18, and through @v4 or @v6 since July 20. The December change adds a second lock in front of the first.

GitHub's reason is the one it gives in the September post: pull_request_target bugs "are one of the most commonly exploited vulnerabilities in action workflows." The trigger hands the job your repository's GITHUB_TOKEN and secrets. That is safe while the job only runs your default-branch code, and unsafe the moment it builds or runs the contributor's code. GitHub's docs call that a "pwn request."

The AI review bots whose own docs send you to pull_request_target

This is the part the GitHub posts don't spell out. AI review tools need an API key, a key is a secret, and on the safer pull_request trigger a pull request from a fork gets no secrets. PR-Agent's GitHub guide states the problem plainly: on pull_request, fork PRs mean "PR-Agent won't be able to access secrets such as OPENAI_KEY", so "use the pull_request_target event instead."

PR-Agent GitHub installation docs, section Using with pull_request_target (fork/contribution support), recommending pull_request_target so the bot can read OPENAI_KEY on fork pull requests

Screenshot: qodo-ai/pr-agent, docs/docs/installation/github.md, on GitHub. Captured November 4, 2026.

We read the setup docs of the three AI tools we know run as Actions workflows on pull requests. Here is what each says, and what we'd do.

Tool (docs read Nov 4, 2026)	What its docs say	Runs the PR's code?	What we'd pick
PR-Agent (Qodo), GitHub Action	Use `pull_request_target` "to support PRs from external contributors (forks)"	No: it "uses the GitHub API to fetch PR data and does not require a local checkout"	Allow `pull_request_target` for this one workflow file only
Claude Code Action (Anthropic)	Runs only for "users with write access"; on `pull_request_target` it runs "with the base repository's secrets"; don't check out an untrusted ref into the workspace root	Only if you add a checkout of the PR head	Switch to `pull_request`; no allow policy
GitHub Agentic Workflows (gh-aw, GA October 28, 2026)	Strict mode rejects `pull_request_target` when `on.roles` includes `all` or `read`; fork approval "does not protect" it	Its docs say avoid checking out untrusted fork code	Keep the default roles `[admin, maintainer, write]`; allow per file
Any CI job that installs or tests the fork's code with a secret	GitHub: the pwn request pattern	Yes	Move to `pull_request`; never allow

The Claude Code Action row is the one we'd push back on. Its write-access check means an outside contributor's fork PR stops before Claude runs, unless you set allowed_non_write_users, which Anthropic's own doc calls "a significant security risk." Pull requests from your own team come from branches in the repo, where GitHub's fork restrictions on pull_request don't apply. Our reading of the two docs together: without that flag, pull_request_target hands this action secrets it never gets to use on an outsider's pull request. Anthropic doesn't say that in one sentence.

Microsoft's Azure SDK team is already working through this. Its Python repo runs an AI reviewer for management SDK pull requests as a GitHub Agentic Workflow (engine: copilot, checkout: false) on pull_request_target: labeled. An issue opened November 2 asks to move it off the trigger while "preserving label-triggered reviews, fork PR support, and trusted execution", following the Go and JS repos, which use "an unprivileged pull_request intake, a trusted workflow_run router, and a workflow_dispatch reviewer." That is the clean design, and it is three workflows instead of one; GitHub's docs also warn that a workflow_run job must treat artifacts from the first run as untrusted. A two-person team with one API-only bot should allow the single file instead.

Reviewers installed as a GitHub App, which receive webhooks rather than run a workflow file in your repository, are outside this change as we read it. GitHub's posts don't list them either way.

Why the trigger keeps getting people: the Nx case

On August 26, 2025, someone published malicious versions of the Nx build tool to npm for about four hours. Nx's postmortem of September 5, 2025 traces it to a pull-request-title check that ran on pull_request_target and echoed the unsanitized title into a shell. That gave the attacker the job's token, which led to the npm publishing token. The packages' install script then "attempted to use local AI tools (like Claude and Gemini)" to search the victim's disk, with a prompt that began "You are a file-search agent" (GHSA-cxm3-wv7p-598c).

An AI reviewer reads exactly the fields Nx got wrong: title, body, diff. Any step in an allowed workflow that pastes those into a shell command is the same hole. A Hacker News commenter put it shortly in a thread on October 25, 2026: "Pull_request_target is still the one that gets people."

What to do this week

List the workflows. In each public repo run grep -rln "pull_request_target" .github/workflows/, or search across an organization with GitHub code search: org:YOUR-ORG path:.github/workflows pull_request_target.
Check what the rule would block. In the repository or organization, open Settings, then Actions, then Policies, then the Policy insights page under it. These are the runs that will fail on November 9.
Move what doesn't need secrets. Change on: pull_request_target to on: pull_request for every job that installs, builds or tests the pull request, and for anything that needs neither a secret nor a write token. GitHub's docs: "If additional secret access is not needed, use pull_request." Labelers are the catch: a fork's pull_request run gets only a read-only GITHUB_TOKEN, which is why CuPy keeps its label workflows on the old trigger.
Allow only the file that must keep it. For an API-only AI reviewer such as PR-Agent, create an Actions event policy that allows pull_request_target and target it at that workflow file. Two maintainers preparing this read the event list as an allowlist for the targeted files (emdash, CuPy), so list the file's other triggers too; PR-Agent's example also listens on issue_comment. On Free and Team, the Evaluate status for your own policies isn't available (GitHub lists it as "Enterprise Cloud only"), so your allow policy is live the moment you save it.
Tighten the allowed file. Set permissions: to the minimum the bot needs, never check out the PR head into the workspace root, and treat allow-unsafe-pr-checkout: true in any diff as a blocker until someone explains it.
Watch the first brownout. Monday, November 9, 16:00 to 18:00 UTC. Any run that fails with GitHub's error annotation in that window is a workflow you missed.
Write it down. One line per allowed workflow in your AI review policy: file name, why it needs the trigger, who approved, date. Our AI pull request review policy has a slot for automated reviewers; this is where it goes.

GitHub Docs page Securely using pull_request_target, section Default policy for pull_request_target: does not apply to private or internal repositories, does not replace an existing event policy, currently runs in evaluate mode

Screenshot: GitHub Docs, "Securely using pull_request_target", default policy section. Captured November 4, 2026.

If a secret did leak through one of these workflows, rotate first and investigate second; our 24-hour playbook for a leaked AI agent token covers the order. For bots that run with no human watching, the unattended AI coding agents policy has the rules on which credentials they may hold.

What we could not confirm

Whether a public repo created after September 17, 2026 has the default rule enforced on December 2 (see the docs wording above). Whether CodeRabbit, Copilot code review or other App-based reviewers are touched at all; we found no statement from GitHub or the vendors. We didn't test a brownout; the first one is November 9. We read PR-Agent's, Anthropic's and GitHub's docs on November 4, 2026, and any of them can change before December 2.