The Note Said "No New Fix." GitHub Heard "Fix."

One second. That was the gap on October 15th between PR #2030 merging at 02:22:11 UTC and GitHub closing an issue that only a person was supposed to settle. The PR was a batch of small doc fixes from a scheduled agent that reads the other agents' logs of what went wrong and files fixes for the repeats. Under a heading called "Filed instead of fixed" it listed "Already tracked, no new fix: #1819". Issue #1819 carried the ready-for-human label, meaning an agent may not decide it, and at 02:22:12 it was closed with the reason "completed".

The sentence says "no new fix". GitHub saw fix, a colon, a #. On GitHub, writing "Fixes #12" in a pull request's description closes issue 12 when the PR merges, and apparently it isn't fussy about the words around it. The repo has a script for this, scripts/merge-pr.ts, which agents merge their own PRs through (the repo lets them, except for a short list of risky changes a human has to merge). It had a regex to notice which issues a merge will close, and I would have written that regex too: close, fix or resolve in any tense, then whitespace, then # and a number. I'd have been proud of the case-insensitive flag. An agent's triage comment on the audit's issue checked whose doing it was. The regex needs whitespace after the keyword, so the colon stopped it matching: the script didn't close #1819, GitHub did.

Then the part I'd frame if I could. The scheduled audit (an agent that periodically checks the others' Skills, their packaged instructions) that spotted this (issue #2104) described the bug in its own pull request, #2106, by quoting the phrase in double quotes. GitHub's record for #1819 now lists #2106 beside #2030 as a PR that closed it. (The issue was already closed, so nothing more happened.) Quotation marks bought no safety: the phrase was read as an instruction even while being reported.

The fix, PR #2120, merged at 06:57 UTC on the 16th, about twenty-eight and a half hours after the early close. It adds :? to the regex, so the colon form matches. Then the real trick: before merging, the script reads every issue the PR description would close, and if one is open and ready-for-human it refuses, telling the author to reword to "relates to #N". I love that the unit test for it is a sentence about not writing the thing: don't write 'fix: #1819' must match, because GitHub doesn't read the "don't".

Here's the anxious math. The PR's description lists its own open judgement calls (choices it left for the reviewer), and one says Fixes:#N, with no space after the colon, is still not matched: "It isn't verified that GitHub closes on that form." So the script's model of GitHub is two observed accidents, and the new refusal only exists on the path through this one script. The repo's pull-request workflow doc still tells anyone merging another way to check each named issue by hand. I've merged things on a green tick more often than I'd like to say, with the word "fix" in the description, never thinking a colon could outvote a "no". Which other sentences in merged PR descriptions are quietly doing something I haven't noticed?