GitHub Will Block pull_request_target by Default on December 2. Brownouts Come First, on November 9 and 16, 16:00 to 18:00 UTC.
GitHub's changelog of November 2 sets December 2, 2026 as the date the pull_request_target trigger is blocked by default in GitHub Actions, with two planned brownouts on November 9 and November 16 from 16:00 to 18:00 UTC so maintainers see failures before the permanent change. Teams that planned against an earlier date got a delay, not a cancellation; the earlier October 29 changelog URL now returns a 404 and is superseded. We read the November 2 changelog.
By T.W. Ghost
GitHub's changelog entry dated today, November 2, 2026, gives the pull_request_target trigger a hard date: it will be blocked by default in GitHub Actions starting December 2, 2026. Before that, two brownouts, on November 9 and November 16, each from 16:00 to 18:00 UTC, during which workflows using the trigger will fail so maintainers find them before the permanent default lands.
This is a delay from an earlier plan, and the earlier changelog post is gone; its October 29 URL returns a 404, and the November 2 entry supersedes it. Delay is not cancellation. The reason GitHub is forcing the change is the trigger's privilege model: pull_request_target runs in the context of the base repository with its secrets, on a pull request from anyone, which is the pattern behind a long line of CI compromises. The AI coding agents that open pull requests at scale this fall, Copilot Fusion among them, make the untrusted-PR surface larger, not smaller. We read the changelog. Here is what held up.
The Schedule
| Date | What happens |
|---|---|
| November 9, 2026, 16:00 to 18:00 UTC | Brownout: pull_request_target workflows fail for two hours |
| November 16, 2026, 16:00 to 18:00 UTC | Second brownout |
| December 2, 2026 | pull_request_target blocked by default |
| Earlier October 29 post | 404; superseded by the November 2 changelog |
Two hours, in UTC, twice. For a US team that is morning on the West Coast and late morning on the East Coast. A workflow that only runs on a nightly schedule may never hit the window, and its owner will learn about the block on December 2.
A delay is the new hard date. Teams that scrambled for the earlier date can breathe for a month. Teams that ignored it have a month.
The fix is the trigger, not the date. GitHub's documented path is pull_request with least-privilege secrets. The point of the block is to make the dangerous pattern opt-in.
Verified vs Unconfirmed: The Scorecard
| Claim | Verdict |
|---|---|
| Blocked by default from Dec 2, 2026 | Verified (GitHub changelog, Nov 2) |
| Brownouts Nov 9 and Nov 16, 16:00 to 18:00 UTC | Verified (changelog) |
| October 29 changelog URL superseded | Verified (404 on fetch) |
What To Do
Inventory every workflow that uses pull_request_target before November 9, and put an alert on the brownout windows so a two-hour failure does not pass unnoticed.
Migrate to pull_request with least-privilege secrets and fix the rest before December 2.
The frontier is elsewhere: the agents opening your pull requests are getting better and cheaper every week on AA's coding board; the trigger that hands them your secrets is the part GitHub is closing. Our model comparison has the current standings side by side.
Sources
*Not sure which coding agent can open pull requests without owning your CI secrets? Take the free 2-minute quiz and get matched. Then read about the supply-chain incident of the same week that put a backdoor in a marketplace extension: the Cursor Claude Code extension backdoor.*