What closing an issue does
You finished the work, the bug is fixed, and the issue is still sitting open in your tracker.
Or maybe someone filed something that should never have been an issue at all.
Now you face a small but real decision: close it, or delete it entirely?
The short answer: closing is almost always the better choice.
Deleting removes the record permanently, and GitHub gives that power to far fewer people for a reason.
This guide walks through what each option actually does, who is allowed to do it, and how to decide in common situations.
Closing marks an issue as resolved, handled, or no longer planned.
The issue stays visible in the repository, its full conversation and history remain intact, and anyone can still find it through search or by link.
Per GitHub Docs: closing an issue, you can close an issue when bugs are fixed or feedback is acted on.
Closing can also show that work is not planned.
Closing is also reversible in practice.
A closed issue can be reopened by people with the right permissions, so a mistake is easy to correct.
That alone makes closing the low-risk default.
GitHub also lets you pick a reason when closing.
Next to the close button you can select a reason such as completed or not planned.
Using the right reason matters: it tells future readers whether the work was done or deliberately declined, which is exactly the context they will look for.
Who can close an issue
Anyone can close an issue they opened themselves.
For issues opened by others, the rules depend on the repository type.
In a repository owned by a personal account, the owner and collaborators can close issues.
In a repository owned by an organization, people with triage permissions or greater can close issues opened by others GitHub Docs.
Issues can also close automatically when a pull request or commit message references them.
Writing 'fixes #12' in a pull request description is one example.