Close an automated fix PR when it targets the wrong thing, jumps further than needed, fails checks for a real reason, touches code nobody owns, or fixes a finding you have formally accepted. Always record why, because a silent close teaches the tool nothing and leaves auditors guessing.
Signals worth closing for
The finding is not real for you. The vulnerable function is never called, or the package is only used in a build tool that never ships. If you are certain, document it as not exploitable and close the PR. Do not leave it open to rot.
The version jump is larger than needed. If a patch release fixes the issue and the PR proposes a major bump, close it and ask for the smaller fix, or open one by hand.
Checks fail for a genuine reason. A failing test caused by the upgrade is information. Either fix the code in a separate PR first, or close and track the migration as work.
The PR touches unexpected files. CI config, scripts or unrelated modules in a dependency fix PR are a red flag. Close and investigate how it got there.
It duplicates another PR. Two PRs fixing the same package, or a group PR that overlaps a single one. Keep one.
It is superseded. A newer fix release appeared. Close the old PR in favor of the new one.
The repository is dead. If nobody maintains the project, merging into it helps nobody. Archive or assign an owner first.
What to record
Write a short reason in the PR comment. Use a small, fixed set of reasons so you can count them:
- Not reachable
- Version too large
- Breaks tests
- Duplicate
- Superseded
- Unowned repository
- Accepted risk
Counting these reasons feeds your fix PR quality metrics. If "version too large" dominates, the tool's strategy is too aggressive and needs tuning. If "not reachable" dominates, your prioritization needs reachability evidence.
Do not just close and forget
A closed PR with a real finding behind it is still an open risk. Choose one of three follow ups:
- Accepted risk. Record owner, reason, review date.
- Work item. The fix needs a human, so create the ticket. See fix PR or ticket.
- Wait for a better fix. Set a reminder.
Some tools reopen or recreate PRs. Check how to tell yours to ignore a specific version or package, and use that instead of repeated closing.
Closing is healthy
Teams sometimes feel a closed bot PR means failure. It does not. A reviewer who closes with a reason is doing the job. The warning sign is the opposite: a queue where nothing is ever closed because nobody reads.
Quick check
Will a closed PR come back?
It depends on the tool. Some recreate PRs for the same update unless you configure an ignore rule. Check your tool's documentation and set the rule when the decision is permanent.
Safeguard keeps remediation on manual approval by default, so closing a PR is a normal, supported outcome.
Last reviewed: 19 October 2026.
