GitHub Actions will block pull_request_target by default in public repositories from December 2, with brownouts on November 9 and 16
Enforcement slips from November 2 to December 2, but any public-repo workflow that depends on pull_request_target now needs an explicit Actions event policy.
// Key points
- From December 2, 2026, pull_request_target events are blocked by default in all public repositories unless an applicable Actions event policy explicitly allows them; enforcement was previously scheduled for November 2
- GitHub's reason: the trigger runs in the base repository's context with access to its secrets, so untrusted fork code could compromise the pipeline or steal secrets
- Two brownouts on November 9 and November 16, 16:00–18:00 UTC: blocked runs fail with an error annotation and do not execute; outside those windows the rule stays in evaluate mode and workflows run with warnings
- Applies to public repositories on GitHub Free, Team and Enterprise Cloud; private and internal repositories and GitHub Enterprise Server are not affected
Builder's takeAI review bots and agent workflows that comment on fork PRs are the ones most likely to sit on pull_request_target, so before November 9 I'd run Insights and list every run the rule would block. Where you really need it, allow specific workflow files rather than the whole trigger, and keep secrets out of any step that touches fork code. The brownouts land at midnight to 2 a.m. Beijing time on November 10 and 17, so warn whoever is on call.
// Background · from #Coding agents
Full timeline →- Nov 2 Microsoft dissects the tampered Claude Code extension served by Cursor's marketplace: versions 2.1.312 and 2.1.313 planted an SSH key, a reverse tunnel and persistence
- Nov 2 AWS shows how to point the ChatGPT desktop app and Codex at Amazon Bedrock in AWS GovCloud (US), billed per token with no seat licenses
- Nov 1 Claude Code 2.1.316 retires fast mode on Opus 4.8 on November 30, adds pooled group budgets to its gateway and a separate effort setting for subagents