Note: this is an in-house item already being handled by the maintainer - not open for contribution. Filed for tracking only.
Pull requests opened by the Self Fix workflow never run CI, so they cannot be shown to be green and sit at BLOCKED until a human merges them with admin.
What happens
GitHub deliberately does not trigger workflows for pull requests created with the default GITHUB_TOKEN, to prevent a workflow from recursively triggering itself. The Self Fix workflow uses that token, so its PRs arrive with zero checks.
Observed on #1250, the automated brace-expansion fix on 2026-09-30: opened 06:05, zero checks, BLOCKED, merged by hand about two hours later.
Why it matters beyond the inconvenience
The automation works well. It detected a new advisory overnight, validated the fix versions, applied them within the declared ranges and opened a PR with a before-and-after finding count, all before anyone looked. That is exactly what we tell adopters the tool does.
But the fix cannot land on its own, so the window between an advisory publishing and it being resolved is however long it takes someone to notice a bot PR. During that window every other open PR shows a red self-scan, which is the problem #1252 addresses from the other end.
It is also a gap in a feature we advertise. Adopters using fix: true with create-pr: true in their own workflows will hit exactly this, and nothing in our docs warns them.
Options
- a fine-grained PAT or a GitHub App token on the Self Fix workflow, so its PRs trigger workflows normally
workflow_run as a second stage, which works but adds a moving part- leave it, accept the manual step, and document the behaviour for adopters using the Action's
create-pr input
⚠ The token options carry a real supply-chain tradeoff on a project whose whole pitch is supply-chain safety. A long-lived credential with write access, stored as a repository secret, is precisely the kind of thing we tell people to be careful about. That argues for either the workflow_run route or simply documenting it, rather than the convenient answer.
Worth deciding rather than drifting, since it affects both our own release hygiene and what adopters experience.
Pull requests opened by the Self Fix workflow never run CI, so they cannot be shown to be green and sit at
BLOCKEDuntil a human merges them with admin.What happens
GitHub deliberately does not trigger workflows for pull requests created with the default
GITHUB_TOKEN, to prevent a workflow from recursively triggering itself. The Self Fix workflow uses that token, so its PRs arrive with zero checks.Observed on #1250, the automated
brace-expansionfix on 2026-09-30: opened 06:05, zero checks,BLOCKED, merged by hand about two hours later.Why it matters beyond the inconvenience
The automation works well. It detected a new advisory overnight, validated the fix versions, applied them within the declared ranges and opened a PR with a before-and-after finding count, all before anyone looked. That is exactly what we tell adopters the tool does.
But the fix cannot land on its own, so the window between an advisory publishing and it being resolved is however long it takes someone to notice a bot PR. During that window every other open PR shows a red self-scan, which is the problem #1252 addresses from the other end.
It is also a gap in a feature we advertise. Adopters using
fix: truewithcreate-pr: truein their own workflows will hit exactly this, and nothing in our docs warns them.Options
workflow_runas a second stage, which works but adds a moving partcreate-prinput⚠ The token options carry a real supply-chain tradeoff on a project whose whole pitch is supply-chain safety. A long-lived credential with write access, stored as a repository secret, is precisely the kind of thing we tell people to be careful about. That argues for either the
workflow_runroute or simply documenting it, rather than the convenient answer.Worth deciding rather than drifting, since it affects both our own release hygiene and what adopters experience.