GitHub Actions: pull_request_target brownouts start 9 November, and workflow lockfiles are GA

Two GitHub Actions changes are worth putting on the calendar this month. One has a date that breaks workflows; the other gives you a better way to pin what runs.

pull_request_target: brownouts on 9 and 16 November

GitHub said on 2 November 2026 that starting 2 December 2026, Actions will block pull_request_target events by default in all public repositories unless an applicable Actions event policy explicitly allows them. Enforcement had previously been scheduled for 2 November. Private and internal repositories are not affected, and the change applies to GitHub Free, Team and Enterprise Cloud, not Enterprise Server.

Before then, GitHub will enforce the rule temporarily in two brownouts:

• 9 November 2026, 16:00 to 18:00 UTC (18:00 to 20:00 IST)
• 16 November 2026, 16:00 to 18:00 UTC (18:00 to 20:00 IST)

During a brownout, blocked pull_request_target runs in affected public repos create failed runs with an error annotation and do not execute. Outside the windows, the rule stays in evaluate mode.

The reason is the trigger itself: pull_request_target runs in the base repository’s context with access to its secrets, so a workflow that executes code from a fork can leak them. To prepare, GitHub says to use Insights to see which runs the rule would block, then either keep the block or allow pull_request_target in an event policy, targeting specific workflow files.

Workflow lockfiles are GA

On 28 October, workflow dependency lockfiles reached general availability on Enterprise Cloud (including data residency), Team and Free plans. The gh actions-lock CLI extension generates .github/workflows/actions.lock, which pins direct and transitive action dependencies to commits. Workflows keep readable @v4 style references, but onboarded workflows run the locked commit even if the tag moves.

The docs add details: every dependency of an onboarded workflow must be in the lockfile, the locked commit must be reachable from the recorded branch or tag in the action’s own repo (fork-only commits are rejected), and the lockfile records numeric owner and repository IDs so Actions can confirm at run time that the repository behind the name is still the one you locked. It does not pin reusable workflow calls, which still need a full SHA. Dependabot regenerates the matching entry in its version-update PRs, admins can enforce a Require lockfile policy, and a check mode can fail CI on a stale lockfile.

GitHub’s own caveat: a lockfile guarantees you run the commits you locked, not that those commits are safe. Review before locking.

Why this matters

If a public repo runs an AI reviewer, labeler or comment bot on pull_request_target, it may fail for two hours on Monday 9 November and stop for good on 2 December unless you allow it on purpose; check Insights now. Lockfiles close the moving-tag gap that hand-pinned SHAs left open for transitive actions, but they move the trust decision to the Dependabot PR, so do not auto-merge those. Both changes reduce the same risk we covered with self-hosted runners that run whatever a PR sends, and they matter more as agentic workflows put more automation in Actions.