GitHub: check your app's automatic jobs before November 9

Find out whether your project is affected

If your app's code is public on GitHub, check its automatic jobs before November 9. A short review can help useful checks keep running during two planned test windows. Private and internal projects are not affected by this change.

GitHub Actions runs automatic checks and jobs around a code project. This notice concerns one trigger, the instruction that starts a job, named pull_request_target. It runs with the main project's access and can reach private service keys. That access needs care if a job executes code from an outside contributor's proposed change.

On November 2, GitHub announced temporary test windows for a default protection that blocks this trigger in affected public projects unless an applicable policy explicitly allows it. Projects whose jobs do not use this trigger are outside the notice.

Read the announcement: GitHub: November test windows and December 2 default protection.

Know when the test windows happen

The windows are November 9 and November 16, both from 16:00 to 18:00 UTC. That is 17:00 to 19:00 in Stockholm. During each window, affected attempts create failed runs with an explanation, and the blocked jobs do not execute.

After each window, the default protection returns to evaluation mode: jobs can run with warnings about what enforcement would block. Permanent enforcement starts December 2. That date was already published in an October 21 update; it was not first postponed today.

The notice covers public projects on github.com using GitHub Free, Team or Enterprise Cloud. It does not cover GitHub Enterprise Server, the version a company runs on its own systems.

Review the job before changing access

Ask the project administrator to open policy insights, where GitHub shows jobs the protection would block. Review each affected job and why it needs its current access. A deliberate review is more useful than changing permissions simply to remove a warning.

1. List the affected jobs and what each one does for your app.
2. Check whether the job needs this trigger or can use an appropriate less privileged alternative.
3. Keep the default block when the trigger is unnecessary. If it is essential, have the administrator review it before allowing a specific job through policy.
4. Confirm useful checks still run, and record who owns the decision.

Learn what starts the work and what it can reach

Our perspective is that this is a useful skill for anyone building with AI: understand what starts an automatic task and which private information it can reach. If someone builds your app for you, asking those two questions helps you understand its upkeep without learning every setting.