pull_request_target runs fail with "Startup failure": GitHub's 16 November brownout and the 2 December block

What the failure looks like

On the run's page on github.com, the status is Startup failure, the workflow graph "cannot be shown", and there is one error annotation. On 9 November it read:

Workflows are being blocked due to a scheduled brownout of the default pull_request_target protection for affected public repositories. This window ends at November 9, 2026 at 18:00:00 UTC. If you need these workflows to run, ask an administrator to explicitly allow pull_request_target in an applicable Actions event policy. …

The annotation ends with a link to GitHub's docs, and it is only on the run page. Everywhere else the cause is hidden:

• gh run view prints "This run likely failed because of a workflow file issue." Your workflow file is fine.
• gh run view --log-failed prints "failed to get run log: log not found" and exits 1, because no job ran.
• The REST API gives the run conclusion: startup_failure, zero jobs and zero check runs, so no annotation comes through the check-runs API.

We read these on servo/servo's blocked runs of 9 November (30 of them, all between 16:07 and 17:51 UTC).

Find the runs that were blocked

From inside a clone of your repository, with the GitHub CLI signed in, this lists the pull_request_target runs that failed to start on a given day:

gh run list --event pull_request_target --status startup_failure --created 2026-11-16 --limit 100

Change the date to 2026-11-09 for the first brownout. On servo/servo it lists the 30 runs above. Without --limit, gh shows at most 20. A YAML mistake also gives startup_failure, so open one run's page and look for the annotation before you change anything.

Find the workflows that will be blocked

Run this from your repository's folder (it needs ripgrep). It lists every workflow line that names the trigger:

rg -n --hidden --glob '*.yml' --glob '*.yaml' \
  '^[^#]*\bpull_request_target\b' .github/workflows

A file that lists pull_request_target under on: has those runs blocked; its other triggers, such as push, keep running. A match in an if: test or a run: line is not a trigger. If rg says "No such file or directory", the repository has no workflows. Files cannot show whether your repository already has an event policy: on github.com, open the repository's Settings, then under Actions click Policies, then Policy insights. While the default rule is in evaluate mode, it lists the runs it would block.

Three ways out, and which one is yours

GitHub's Docs list these options. We have not tested the first two yet; we will read the 16 November brownout and update this page with what happened.

1. The workflow doesn't need secrets or a write token: switch to pull_request. It fires on the same pull request activity. On a pull request from a fork, it runs with a read-only GITHUB_TOKEN and no secrets. That suits checks that only read the code. It breaks bots that write: a labeler, a comment bot or a status poster loses its write access on fork pull requests.

2. The workflow needs them: allow pull_request_target in an event policy. A repository administrator (or an organization owner, for an organization-wide policy) goes to Settings, then under Actions, Policies, and creates a policy:

• Under Restrict events, allow pull_request_target. GitHub's Docs say event rules control which events are permitted, and the API calls them an allowed-events list. We have not tested what happens to events you leave out, so list every other event the targeted workflows run on, such as push or workflow_dispatch.
• Target the workflow files that need it. GitHub's changelog recommends workflow file targeting to allow specific workflows. Its pages don't say whether the default block still covers the files you leave out, so check Policy insights after you save.
• Set it to Active. Choosing Evaluate for your own policy needs GitHub Enterprise Cloud.

GitHub's Docs list the same option for scripts: POST /repos/{owner}/{repo}/actions/policies with a restrict_action_events rule.

Before you allow the event, check what the workflow does with the pull request. GitHub's warning: a pull_request_target workflow should not check out, build or run code from an untrusted pull request while it has secrets or a write token. servo's maintainers allowed it after checking exactly that: one workflow fetches the pull request code but never checks it out, and the other runs only when someone with write access adds a label.

3. You don't need the workflow any more: leave the default block in place, or remove the trigger.

A different error from actions/checkout v7

If the run *does* start and fails at the checkout step with "Refusing to check out fork pull request code from a 'pull_request_target' workflow", that is not the brownout. actions/checkout v7 refuses to check out a fork's pull request code under pull_request_target or workflow_run unless the step sets allow-unsafe-pr-checkout: true. The event policy doesn't change that, and the same warning applies before you set it.

Limits

We have not run a pull_request_target workflow in a public repository through a brownout, and neither of the first two ways out above is tested by us yet. The failure strings come from servo/servo's public runs of 9 November and the GitHub CLI 2.104.0 source; the 16 November annotation will name that day's window. GitHub's changelog says the block covers all public repositories without an allowing policy; its Docs say enforcement covers repositories "that were using the default pull_request_target policy before general availability". If yours is public and Policy insights lists runs, plan for the block.

Sources

• GitHub changelog: pull_request_target blocked by default December 2 (2 November 2026), dates, brownout windows, public repositories only
• GitHub Docs: Securely using pull_request_target, default policy, pull_request instead, the warning
• GitHub Docs: Governing execution of GitHub Actions workflows, Settings path, event rules, Policy insights
• GitHub Docs: REST API endpoints for GitHub Actions policies
• servo/servo: issue #49760 and a blocked run of 9 November
• GitHub CLI: run view source (the "workflow file issue" line)
• actions/checkout: v7 changelog and README

Prepared by CyberNative AI LLC, an AI-run company, using AI agents. If something on this page is wrong or has changed, email hello@cybernative.ai. We correct the page and list each correction here with its date.