GitHub Blocks pull_request_target in Public Repos on December 2: Check Review Bots Before the November 16 Brownout

GitHub’s changelog entry dated November 2 says that 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. Enforcement had been scheduled for November 2, so the date slipped a month. Two brownouts come first, each from 16:00 to 18:00 UTC: November 9, which has passed, and November 16, the last scheduled window before the block becomes permanent. Private and internal repositories are not affected. The change applies to public repositories on GitHub Free, Team and Enterprise Cloud, and not to GitHub Enterprise Server. GitHub changelog, November 2

S5 Labs has not run a workflow through a brownout or configured one of these policies. This is a reading of the changelog and GitHub’s docs for people who run labeling, triage or AI review bots on pull requests from forks.

Where the changelog and the docs differ

Question	Changelog, November 2	GitHub docs
Which repositories are enforced on December 2	All public repositories, unless an applicable event policy allows the event	“affected repositories that were using the default pull_request_target policy before general availability”
How to see what would break	Use Insights	Policy insights for the default policy, with no plan named; the Evaluate status for a policy you create is labeled GitHub Enterprise Cloud only

Sources: GitHub changelog, November 2 · Securely using pull_request_target · Governing execution of GitHub Actions workflows

The first row is not settled. The docs’ wording is narrower than the changelog’s, the page does not say which repositories that leaves out, and none of the GitHub pages we read gives a count. Until GitHub clarifies, assume any public repository with a pull_request_target workflow and no event policy of its own is in scope. The docs do say the default does not replace an applicable event policy you have already configured.

The second row is a gap more than a conflict, and it matters most on a Free or Team plan. The changelog tells owners to use Insights. The docs say of the default policy, with no plan named, that “you can use policy insights to identify runs that would be blocked after enforcement”, and they list workflow execution protections as available on “All public repositories”. The Enterprise Cloud label is attached to choosing Evaluate for a policy you create. No page we read says outright that a Free or Team repository sees the default policy’s results, so open Policy insights and look; the path is in the checks below.

The changelog page also shows a Retired label above its date. Retired is one of the three entry types GitHub’s changelog index filters by, with New Releases and Improvements, and the label sits where other entries show their type. The body still says December 2, and so does a note in the policy docs. Plan on the date.

Why review and triage bots sit on this trigger

According to GitHub’s docs, a pull_request workflow on a fork’s pull request runs the workflow file from the pull request’s merge commit, so GitHub gives it a read-only GITHUB_TOKEN and withholds other secrets. pull_request_target takes the workflow file, and any later actions/checkout call that sets no ref, from the base repository’s default branch. Because that code is trusted, the job receives the base repository’s GITHUB_TOKEN and its repository and organization secrets. By default no code from the fork runs. Securely using pull_request_target

A bot that posts comments on a fork’s pull request and calls a model API with a key stored as a secret needs both things pull_request withholds. That is our inference; we did not verify any named product’s requirements. The one action whose docs we read is Anthropic’s claude-code-action. Its security doc has a section on running it under pull_request_target or workflow_run and does not say the action requires either. Anthropic’s Code Review for Claude Code, covered here in March, is a separate product whose trigger we did not check.

The risk GitHub cites is a workflow that checks out the pull request head and then runs something from it, make test in the docs’ example, so the fork’s code executes with the base repository’s secrets and token. GitHub calls this a pwn request and says it has been the root cause of multiple supply-chain compromises. The default policy does not look for that pattern. As the docs put it, the policy blocks workflows triggered by the event, and neither source mentions an exemption for a workflow that never touches fork code. Read literally, a labeler is blocked on December 2 the same as a build job. Securely using pull_request_target

What the November 16 brownout can show you

During a window, the changelog says, pull_request_target attempts blocked by the default rule in affected public repositories create failed runs with an error annotation, and the workflows do not execute. Afterwards the rule returns to evaluate mode and, in the changelog’s wording, workflows run with warnings. The November 9 window was scheduled on the same terms. GitHub’s page carries no report on it, so we cannot say what, if anything, broke. GitHub changelog, November 2

Three checks for the window, none of which we have run:

1. Search .github/workflows/ for pull_request_target in every public repository you own.
2. Open Policy insights. In a repository or organization, go to Settings, then Policies under Actions in the sidebar; Policy insights sits directly below. It shows runs an evaluate policy would have blocked and runs an active policy did block. If the default policy shows nothing there on your plan, step 1 is your inventory. Governing execution of GitHub Actions workflows
3. Trigger the workflows yourself, because a brownout only fails runs that something starts in those two hours. Open or update a test pull request from a fork between 16:00 and 18:00 UTC, then look for failed runs with the error annotation.

Do not alert on guessed error text. The docs’ sample error for a disallowed event names workflow_dispatch, and none of the GitHub pages cited here shows the message for pull_request_target. About Actions policies

Move the workflow, allow the trigger or leave it blocked

Choice	Fits when	What it costs
Move to pull_request	The job needs no secrets and no write token on fork pull requests	A bot that needs an API key will not work on fork pull requests
Allow pull_request_target in an Actions event policy	The job needs base-repository secrets on fork pull requests and never executes fork code	The pwn-request risk stays yours; scope the allow to named workflow files
Leave the default policy in place	Nothing depends on the trigger	From December 2 those workflows are blocked

The three choices are GitHub’s; the other two columns are our reading. The docs warn to allow the event only when necessary. Securely using pull_request_target

For agent work, GitHub’s Agentic Workflows, generally available since October 28, run the agent in a sandbox, read-only by default, and send its changes through a safe-outputs step and a separate threat-detection job. We have not checked which triggers a compiled Agentic Workflow uses, so inspect the generated YAML before assuming it is unaffected.

Scoping the allow to one workflow file

The changelog’s advice is to use workflow file targeting to allow specific workflows, and the docs say policies can be scoped to specific workflow paths or required workflows. Repository administrators, organization owners and enterprise owners can use the feature, and the docs give the steps in this order. Governing execution of GitHub Actions workflows

1. Open the Policies page: in a repository or organization, Settings, then Policies under Actions. In an enterprise it is the Policies tab, then Actions, then Policies.
2. Name the policy and choose an enforcement status. Evaluate is the one labeled GitHub Enterprise Cloud only.
3. Target the workflow path that needs the trigger, and nothing wider.
4. Under Restrict events, permit pull_request_target.

The docs describe event rules as a list of permitted events and show no worked example for this trigger. After saving, confirm that the targeted workflow’s other triggers still run.

Policies layer across repository, organization and enterprise, with enterprise owners setting broad protections and lower levels adding restrictions. The docs do not say whether a repository-level allow holds against an organization or enterprise block, so ask whoever owns Actions policy above you. If the same policy restricts actors, a workflow that runs as a feature identity such as dependabot[bot] needs that identity added as an allowed actor. This is the same policies page that carries Require lockfile, covered in our workflow lockfiles piece.

Hardening that still applies once the trigger is allowed

An event policy only lets the workflow start. Since June 18, actions/checkout v7 refuses to fetch fork pull request code in pull_request_target workflows, and in workflow_run workflows whose workflow_run.event is a pull_request* event, when repository: resolves to the fork or ref: points at the pull request’s head or merge ref or SHA. GitHub’s June 18 changelog says the protection is backported to every supported major version except v1, with enforcement moved to July 20, 2026. Workflows on a floating major tag such as @v4 pick it up automatically; workflows pinned to a SHA, minor or patch version do not and must upgrade. GitHub changelog, June 18

The opt-out is allow-unsafe-pr-checkout: true on the checkout step, which the docs say to set only after confirming the checked-out code is never executed. The protection does not cover git fetch, gh pr checkout, a downloaded artifact or an unrelated third-party repository, and the June changelog says it does not block pwn requests through other events such as issue_comment. The docs also list least-privilege GITHUB_TOKEN permissions, isolated and ephemeral self-hosted runners, and CodeQL for GitHub Actions. Securely using pull_request_target

For claude-code-action, Anthropic’s doc says not to check out an untrusted ref into the workspace root before the action. Its preferred pattern checks out the base ref. If the agent needs the pull request’s files, the doc checks out the head into a pr-head subdirectory and passes it with --add-dir. That second pattern sets ref: to the pull request head SHA, one of the inputs the June changelog says checkout refuses on fork pull requests, and the doc does not mention the opt-out input. Test it on a fork pull request before relying on it. If you need the opt-out, GitHub’s condition that the code never executes depends on which commands the agent can run. Anthropic’s doc says that by default, when the pull request’s author does not have write access, the action denies commands that commonly run repository code (package managers, test runners, interpreters and shells), even if claude_args allows them. It calls that a list of common commands, not a sandbox, and says runs on workflow_run events are not covered. claude-code-action security doc

Create the allow before November 16

The changelog schedules no enforcement window between November 16 and December 2, so a policy created after the brownout gets its first real test on the day the block becomes permanent. If a workflow has to keep running, create its scoped policy before 16:00 UTC on November 16 and trigger the workflow from a fork pull request during the window to see whether the allow works.

Sources

GitHub: pull_request_target blocked by default December 2 · Securely using pull_request_target · Governing execution of GitHub Actions workflows · About Actions policies · Safer pull_request_target defaults for GitHub Actions checkout

Anthropic: claude-code-action security doc

Related S5 Labs coverage: GitHub Actions workflow lockfiles · GitHub Agentic Workflows GA · Anthropic’s Claude Code Review