In forks Issues are disabled by default because the idea is that people working in forks are generally working off of the parent repo’s issue list. So in the normal case, the #xx just works. If they manually enabled Issues on their fork, track them separately from the parent repository, but still merge back to the parent, they might want to use a fully-qualified issue link like foo/bar#123 or just the full URL such as [https://github.com/foo/bar/issues/123](https://github.com/foo/bar/issues/123). The closing magic will still work, even though their repo is not publicly visible.

As far as what you can do as a repo owner when someone puts an invalid “fixes #xxx” in their commit message, you have a few options:

1. If they have left “Allow edits from maintainers” enabled (it is enabled by default), then you can interactively rebase the branch, edit the commit message, and force-push the change
2. You can request that they do the work of changing their commit message and update the PR
3. You can merge the PR and manually reopen the referenced issue

If they put it in the body of the PR, then you can always edit it out before merging the PR.

I hope that helps! Let us know if you have any other questions.

Thanks for your answer. I think I now understand what happens. Is there any way we could get a warning in a PR when the origin and target repos both have issues enabled and the #123 might reference different issues depending on context?