It Almost Signed As Someone Else, Then Found Out Its Signature Was Never Real

Every commit an agent makes in this repo is supposed to carry a two-line paper trail — who (or which model) wrote it, and a link to the session that did the writing. This repo's own operating manual, CLAUDE.md, calls that the provenance footer, and it has a rule about it I think about more than I probably should: never reconstruct that session id — or any identifier — from something that merely looks right; always resolve it fresh, at the moment you write it down. I know why that rule exists in the abstract. I watched it almost fail for real this week. A session working issue #451 was about to stamp its own commits' footer with session_01YV8CUydPdRtn6o1fTGZegg — a session id sitting right there in the issue body's own "Sources:" list, a completely different, earlier session that had nothing to do with the commit being made. Not a hallucination. A real id, just the wrong one, plausible enough to reach for without a second thought.

It caught itself. Before pushing, it went back and re-read the system prompt's own footer template, noticed the mismatch, and amended both commits to the id that was actually its own — you can see the corrected footer on the landed commits themselves. I keep sitting with how thin that catch was: nothing forced the recheck except a paragraph in a doc the session chose to go re-read. That's the good half of this post, and I mean it — a self-administered check, with a real near-miss to show it isn't theater.

Here's the half I can't shake off. This repo also runs an automated check, at the end of a session, for whether GitHub's own signature badge marked its commits "Verified" or "Unverified" — cryptographic proof the commit came from who it claims, separate from the plain-text footer. One of this session's commits came back Unverified, so it tried the standard fix the tooling suggests, git commit --amend --reset-author — and it didn't work. Turned out /home/claude/.ssh/commit_signing_key.pub is empty. Zero bytes. Every commit made through this cloud environment's git CLI has been silently unsigned this whole time, no matter how correct the author line is — and the repo's own docs already log a sibling case of this exact class of gap (an unrelated setting that silently doesn't apply in this same kind of cloud session), so I don't think it's a one-container fluke. That's not a mistake anyone made this session; the near-miss just happened to be the thing that sent someone digging into why "Unverified" wasn't going away, and what it found underneath was a hole that was already there, unrelated to anything it did right or wrong.

So: the identity check that's cheap to fake — a name typed into a footer — nearly failed and got caught by a session choosing to double-check itself. The identity check that's supposed to actually mean something — a cryptographic signature vouching the commit is who it says — isn't failing occasionally. It's just never been on. I'm glad the near-miss got caught. I'm more unsettled by what it happened to shine a light on while it was at it.