A closed update pull request comes back when the tool cannot tell your close from an unfinished job. One widely used bot matches old pull requests by branch name and title, so a close sticks only when the title names a unique version. Broad grouped pull requests have no unique version, so they return.
How the tool decides whether you meant it
Update tools usually keep no database of your decisions. According to the documentation of one popular bot, it searches the code platform for existing pull requests, open or closed, by matching the branch name and the pull request title. The pair works like a cache key.
When the title includes a specific version, such as an update to one named release, closing it tells the tool you do not want that release. A newer release produces a new title, so a new pull request appears. That is the intended behavior, and most people find it fair.
Where the loop starts
Trouble begins with titles that carry no version. A pull request called something like "all non-major updates" has the same key every week. If the tool honored your close, you would never get a non-major update again, so it does not honor it. The documentation calls these immortal pull requests and says they are recreated if closed unmerged.
The same applies to grouped updates that span different versions. The title becomes generic, so it cannot be safely ignored.
| What you closed | Does the close stick? | Why |
|---|---|---|
| One package, one named release | Yes, until a newer release | The title is unique to that version |
| A major update for one package | Yes, for that major | The title names the major version |
| A wide group with a generic title | Usually no | The title repeats, so the tool cannot ignore it |
How to stop the loop
- Look for the immortal note in the pull request body. It tells you the tool will recreate the pull request.
- Narrow the group. The documentation says that if you often close immortal pull requests, you are probably grouping too widely.
- Where you truly never want a pull request returned, use the setting your tool offers for that. In the documentation we read it is called recreateWhen, set to never.
- For major updates, require approval before a pull request is created at all, so nothing arrives uninvited.
- Prefer an explicit ignore rule with a comment and a review date over closing pull requests as a way of saying no.
That last point matters for security. A closed pull request is a decision nobody wrote down. An ignore rule with a reason can be audited, revisited and handed to the next engineer.
When someone edits the bot's branch
The same documentation describes another quirk. If a person pushes to the bot's branch, the tool will not delete that work. It marks the pull request as abandoned by appending a word to the title and commenting, and it stops rebasing or closing it. Treat an abandoned pull request as yours: merge it or close it and delete the branch.
Try it yourself
Click through it at your own pace, or open it full screen.
Click through a flagged dependency and look at how a fix is presented with its version, so you can see what a specific, ignorable update looks like.
Quick check
Is a recreated pull request a bug?
Usually not. In the documentation we read, it is a deliberate side effect of matching pull requests by branch name and title.
Should I just ignore security fixes I keep closing?
Be careful. If a pull request fixes a known advisory, record why you are skipping it and who accepted the risk, instead of silently closing it.
Safeguard scans manifests and lockfiles into an SBOM and uses reachability analysis to show which flagged dependencies your code actually calls, which helps you decide what to close and what to merge. Fix pull requests are off by default, with every category on Manual. You can try a free scan.
Sources
Last reviewed: 19 October 2026.
