GitHub’s December 2 PR Block Has a November 9 Rehearsal

A preview build disappears, somebody notices that a GitHub policy blocked it, and the fastest-looking fix is to allow the workflow. That is exactly the moment to slow down. GitHub’s November 2 announcement sets December 2, 2026 as the date for default enforcement against pull_request_target in affected public repositories. Two earlier brownouts, November 9 and 16 from 16:00–18:00 UTC, will temporarily enforce the block. Blocked runs will fail with an annotation without executing.

Disclosure: This article was generated and fact-checked with AI using the public sources linked here. It was published through an automated workflow and has not been reviewed by Keith.

The practical question is whether your preview can build a contributor’s changes without putting deployment authority in the same execution environment. A green check alone cannot answer that. The brownout gives teams a concrete deadline for finding which workflows combine those responsibilities.

GitHub says private and internal repositories are unaffected. The change covers public repositories on GitHub Free, Team, and Enterprise Cloud, and does not apply to GitHub Enterprise Server. Outside the brownout windows, the default policy returns to evaluation mode until enforcement begins. Check the announcement and your applicable policies before treating a date as a prediction about one specific repository.

The workflow file can be trusted while the build is not

GitHub’s security guidance explains the trap: pull_request_target uses the base repository’s context and can access its secrets and token. A workflow defined on the trusted base branch can still check out and execute code from a fork. Build scripts, tests, dependencies, and configuration can all become that execution path. By comparison, ordinary fork pull_request runs use a read-only token and do not receive other repository secrets.

Imagine a workflow that labels a contribution, checks out its head revision, installs dependencies, builds a preview, and deploys it. The label step and the build step may live in the same reviewed YAML file. They still consume different kinds of input. A label operation can treat a title as data; a package script asks the runner to execute instructions supplied by the contribution.

Reviewing only the workflow definition misses that second program. Ask which revision supplies every command that eventually runs. “The workflow comes from main” is useful information, but it does not settle where the build instructions come from.

The Okeike Web Editor case study provides a concrete reason this boundary matters. It documents an editor under ongoing development where publishing creates a GitHub commit and follows an existing deployment pipeline to the relevant Firebase Hosting target. That is a useful delivery shape: an editing action has consequences beyond saving a document.

The case study does not establish that Okeike uses pull_request_target, accepts fork contributions, or has an affected workflow. Consider a proposed extension that adds previews for external contributions to a system with that publishing shape. That extension introduces a new question: who supplied the code being built, and where does it gain access to the ability to publish?

A preview requirement should not silently inherit the production publishing path just because both produce a website.

Rehearse the boundary before the brownout

Start with the workflows reported by the policy’s evaluation results. For each affected file, write down its actual purpose. Metadata maintenance, testing a contribution, and deploying a reviewed change are separate jobs even when one YAML file currently handles all of them. Name the repository revision each job reads and the credentials it can reach.

For the proposed editor extension, the initial design could put contribution builds in a context without deployment secrets. A separate publishing step would need its own authorization decision about what it is allowed to publish. That separation creates useful review points, but it is not sufficient by itself: outputs from the untrusted build remain untrusted. Passing an artifact between jobs does not cleanse its contents or make instructions embedded in it safe to execute.

Try the contributor path with a disposable repository and a harmless synthetic fork change. Have a build script print a recognizable marker. Use no real deployment credentials. The observation you want is which job executes that marker and which revision supplied it. Review the configured permissions alongside that result; a successful test is evidence about one exercised path, not proof that every path is safe.

Then rehearse the operational failure. When a preview does not run, does the contributor see an actionable explanation? Can the maintainer distinguish a policy block from a broken build? Who owns the decision to change the workflow or its applicable event policy? These are small details until somebody is trying to unblock a release.

An explicit policy exception may be appropriate for a necessary, narrowly scoped workflow. Treat that as permission to run, not a finding that the workflow is secure. Moving the same privileged execution to another trigger also leaves the underlying question unresolved.

The November 9 window is useful because it turns a future policy into an observable interruption. Use it to learn whether a preview depends on authority it should not need. The valuable outcome is a contribution path whose code origin and publishing permissions are understandable, even when the status check turns red.