THE USEFUL ANSWER
GitHub's 2 November notice schedules temporary enforcement of the default pull_request_target block on 9 and 16 November, before permanent enforcement on 2 December 2026. For an affected public-repository bot, inspect the exact trigger and policy insights.
Retain the block, redesign the workflow where appropriate, or obtain a narrowly scoped maintainer-reviewed exception. Do not blanket-allow a privileged event just to keep a bot running.
WHAT YOU'LL LEAVE WITH
A dated maintenance notice and a workflow review sheet that distinguishes continuity from permission safety without claiming every PR bot is affected.
- The first scheduled brownout is 9 November, not the December enforcement date.
- The trigger and applicable policy determine exposure, not whether the bot uses AI.
- Keeping automation running is not a reason to execute untrusted code with secrets.
01Put the nearer date on the maintenance list
GitHub's 2 November 2026 notice moves the previously scheduled 2 November enforcement to 2 December. Two temporary enforcement windows come first: 9 and 16 November, both 16:00 to 18:00 UTC. Blocked attempts create failed runs and do not execute. Between those windows, the default returns to evaluate mode. [1]
The change concerns affected public repositories on GitHub Free, Team and Enterprise Cloud. Private and internal repositories, and GitHub Enterprise Server, are outside this announcement. An applicable policy explicitly allowing the event changes the outcome. Do not infer impact from the repository being public alone. [1]
02Check what the bot runs, not what it is called
An AI reviewer, labeler and conventional test job can use different triggers and permissions. This notice is about the workflow event, not a blanket shutdown of AI bots.
GitHub documents that pull_request_target operates in the trusted base-repository context. Risk appears when privileged work then executes untrusted pull-request code. A build, test, dependency or configuration file can be that execution path. Downloaded artifacts also need a trust decision; renaming the trigger is not a complete security review. [2]
03Make one workflow reviewable
Swipe or scroll to compare
| Field | Record before editing |
|---|---|
| Workflow and owner | Exact file path and accountable maintainer. |
| Scope | Public, private or internal; cloud or server. |
| Event | Actual trigger and applicable policy, not the product name. |
| Required result | Read, comment, label, test or deploy. |
| Trust boundary | Where code and artifacts originate; what executes; what secrets or token permissions are available. |
| Observed impact | Policy insight or failed-run link. Write unknown if it has not been inspected. |
| Recovery | Expected fallback, rollback owner and verification step. |
Use policy insights to establish which runs would be blocked. [2] Keep the resulting review private if it contains repository-sensitive details. This article has not audited your repository or confirmed that any init.news workflow is affected.
04Choose continuity without widening trust
Swipe or scroll to compare
| Option | When it deserves consideration |
|---|---|
| Keep the default block | The workflow is unnecessary or its trust boundary is unresolved. |
| Redesign around a safer event | The job can work with reduced privileges; verify behavior and fork handling. |
| Review a specific exception | The event is genuinely required and an authorized maintainer can justify the narrow scope. |
Do not change all repositories at once. For a necessary workflow, define the expected output and required permissions, then use a controlled test PR after the approved change. Check both successful work and rejection of unintended work. A green run alone does not prove that secrets are protected.
If the boundary is still unclear before the brownout, a temporary manual review is preferable to an unexplained privilege expansion. Record the missed automation work separately from customer delivery impact. This is a proposed maintenance procedure, not a performed security test.
05What to read next
Read the announcement's brownout schedule and the documentation's deciding and hardening sections. Recheck the official notice before each window in case GitHub revises the schedule. [1] [2]
FOLLOW THE EVIDENCE
Sources & checks
- GitHub Changelog: pull_request_target blocked by default December 2, 2 November 2026 ↗
Revised enforcement date, two temporary windows, failed-run behavior and repository/product scope.
CHECKED 2026-11-03 - GitHub Docs: Securely using pull_request_target ↗
Base-repository trust, untrusted execution risk, policy insights and event-selection guidance.
CHECKED 2026-11-03
Sources stay attached so you can check the argument. Meaningful revisions keep this address.