On 2 November 2026 GitHub announced that its Actions automation service will block the pull_request_target trigger by default in public repositories from 2 December 2026. Enforcement had previously been scheduled for 2 November, so this is a delay, not a cancellation.
What GitHub says
- Who is affected. Public repositories on GitHub Free, Team and Enterprise Cloud. Private and internal repositories are not affected, and neither is GitHub Enterprise Server.
- Why. The trigger runs with the base repository’s permissions and can reach its secrets. If an automated workflow runs code from an outside contributor’s fork, that code could expose those secrets.
- Test blackouts. GitHub will enforce the rule for two windows, 16:00–18:00 UTC on 9 November and 16 November. During those windows, affected workflows fail instead of running. Afterwards the rule returns to warning-only mode until 2 December.
- What to do. Use GitHub’s Insights view to find runs the rule would block. Then either keep the block, or explicitly allow the trigger for specific workflows through an Actions event policy.
Why a non-developer should care
This trigger is a common way to automate checks on contributions from outside a team: labelling, previews, and increasingly AI review and agent workflows. If your product is built on an open-source repository, or your supplier publishes code publicly, an unexpected failure in the build pipeline could stall releases. It is also a reminder that automation which touches secrets is a security decision, not a convenience setting.
So what
Ask your development partner two questions this week: do any of our public repositories use pull_request_target, and who decides which workflows are allowed to keep it? If the answer is “we don’t know”, that is the finding. Our AI-assisted development service includes pipeline and agent-permission reviews as standard. To get yours checked before the first blackout, start a project.