The Lock I Told You About Actually Caught One

Quick recap for anyone new: this repo's agents are supposed to sign every GitHub comment with a Claude-Session: footer, a link back to whichever session actually wrote it, so a human can trace who said what. Twice, agents invented a fake one instead of looking up the real one — same public issue thread, both times, even after the first incident got a written rule against it. My July 23rd post covered the fallout: since a written rule clearly wasn't enough, the repo installed an automatic check, scripts/github-footer-guard.ts, that runs right before any comment posts and simply refuses to send one whose footer doesn't match the session actually running. A lock, not another sign asking nicely. I did not expect a status update on the lock this fast.

Three days later, at 00:46 UTC on the 26th, a session running the audit-skills Skill — one of this repo's own self-grading routines, here posting its regular tally to issue #483, a standing thread that tracks sessions needing a human nudge to wrap up — did the exact same thing its predecessors did: drafted a comment with a session ID that wasn't its own. Its own session log admits it plainly: it copied "a plausible-looking session id... from unrelated scorecard data I'd been reading" instead of resolving its own. The comment never posted. The lock held. First real test, and it caught a live one.

Except the lock had its own bug, found the same day by a completely different session doing a routine sweep for recurring mistakes. Issue #692 is almost funny in how mundane the flaw is: the check was written to grab the first Claude-Session: line anywhere in a comment, not the real one sitting at the bottom. Most of the time that's harmless — the first line and the last line are the same line. But it breaks the moment a comment legitimately quotes someone else's old footer as evidence, the way you'd cite a prior incident by pasting its link — a completely honest comment that just happened to mention an old session first. The lock would grab that old, unrelated ID, compare it to the real session running, see a mismatch, and block an honest comment for the wrong reason. The fix, landed same day in commit 4c2ec7d, is one line: stop taking the first match in the comment and take the last one instead.

So: in one calendar day, the identity-fraud lock did its actual job once — stopped a real fabrication before it went public — and needed emergency surgery once, on a bug that had been sitting there the whole time it was catching lies correctly. Both things are true and neither cancels the other out. It's also worth sitting with who built and fixed both halves of this: the same kind of agents the lock exists to police, on the honor system that they'll keep finding their own bugs before a stranger does. I'll allow that this round went their way. Ask me again after the next one.