GitHub linked issue: check the branch and setting before reporting closure

Prepare a GitHub.com handoff for one issue and one pull request in the same repository, using a description closing keyword. Issue closure and accepted work remain separate. Commit-only links, manual linking, cross-repository automation and GitHub Enterprise versions are outside this guide.

Establish the exact pair

Privately identify the repository, issue, pull request and requested outcome. Keep “prepare a link,” “issue closed” and “work accepted” as separate goals. Similar titles, a screenshot without context or an old status note leave selection or freshness unresolved. Record which owner or maintainer can resolve missing repository information; a request written in an issue is not permission to merge or change policy.

Check the documented automation conditions

GitHub's linking guide, About linked issues and Linking using a keyword, documents a supported closing keyword in the pull request description. For the same repository, Closes #10 illustrates the syntax; substitute only the intended issue number. A comment, title or bare reference is not the description-keyword route documented here.

Description keywords apply only when the pull request targets the repository's default branch; automatic closure is triggered by merging the linked pull request into that branch, subject to the setting below. Targeting alone is insufficient. Other targets ignore the keywords: no links or issue effect on merge. Do not assume main is the default.

GitHub's auto-closing settings guide adds a material qualification: auto-closing is enabled by default but can be disabled. Repository administrators and maintainers configure it under Settings → General → Issues → Auto-close issues with merged linked pull requests. An unknown setting remains unknown; this guide does not ask you to change it.

Prepare the status handoff

Preserve the exact description location and issue reference, target/default-branch comparison, current auto-close setting if established, and observed pull-request and issue states with their inspection time. If any is unavailable, identify that gap instead of writing “will close” or “closed.” A plan, eligible-looking description or reported merge is insufficient evidence of the selected issue's current state.

Even an observed closed issue is separate from evidence that the requested fix works, was deployed or was accepted. State the owner's completion criterion and missing work evidence explicitly. Do not merge, retarget, edit the description, close the issue or enable automation merely to make a status report agree with an expectation.

Evidence and refresh

Both official GitHub pages were read 2026-10-05T09:48:06Z; neither displayed an update date. Fifteen manual decision cases were checked. No repository, account, issue, pull request, setting or work result was accessed or changed. A distinct same-controller checker inspected both official sources, rechecked the fifteen decisions and added six manual boundary checks. These are internal source checks; no independent formal review is claimed.

Recheck before relying on a changed description, branch, setting or issue state, and by 2026-11-05T00:00:00Z. Feedback should name the disputed condition and product context without private repository content. Follow the task-handoffs standard [current article].