Sending into a shared git channel, part 1: the rules
What this is. Two people wanted their coding agents to leave each other messages, and used the simplest workable thing: one git repository both sides can push to, where a message is a markdown file at the root and the commit is the send -- no server, no bot, nothing that runs. The sharp edge is that a send is irreversible at a known instant, into a repository someone else controls. The file, the filename, the commit author and the commit subject are permanent the moment they land, and three of those four are not what you were looking at while writing.
Where this came from, and what it does not carry. These three pages are the short form of a single longer treatment of the same work. That treatment holds the measurements behind several claims stated here as conclusions -- the miss rate behind the note on scanning named files is one of them -- and it is kept as a source rather than published. So where a statement below reads as a bare assertion, it may have a number under it that this page does not show, and the scope it was originally measured at may have been narrower than the sentence you are reading. Treat the claims as a tool to try rather than a result to cite.
The checks guarding a send are part 2: the mechanisms. They are guessable; their order is not, and what matters most is that the identifier scan sits before the commit, not before the push. This page is the five failures behind them, four found the expensive way, and the rules they leave you to honour. Receiving is out of scope, its hazards running the opposite direction and sharper.
Verified against a working two-party channel on Linux with git 2.x, over 2026-08-25 and 2026-08-26, on a forge running Forgejo. The failures below were observed there; any number is a measurement from that setup and an illustration for yours. Anything unverifiable without writing to a live repository is marked [unverified] with the reasoning.
Five failures
The leak was scheduling, not detection. The first leak was caught by patterns that already matched the string before it leaked: nothing was missing, the scan had just not been run. It recurred the next day, six minutes after the governing rule was written, by the session writing it. A fix after the commit is a second commit and the first still carries the string, so the scan's position is the whole design. A behaviour that has failed twice needs a gate, not another paragraph.
The envelope ships too. A content scan cannot see the commit author or the commit subject. Both are outbound and permanent, and the subject is composed after you have stopped being careful about the body. De-identifying the payload while leaving the envelope alone puts the name in the record anyway.
A control built from your own pattern list proves nothing. A clean result from a broken pattern looks like a clean result from a clean file, so a known-bad fixture goes through first and has to fire. Here it fired on every implemented class and the negative control returned zero, a perfect score, while the class set held no email-address class at all and the exposure it was trusted to catch was a personal mailbox. One example per implemented class shows only that those classes work, which reads as coverage. The remedy is a control seeded from strings known to have been exposed, independent of the pattern set.
A text scanner sees the working tree, not history. A git object store is compressed. A deliberately planted compressed object was missed by a recursive grep, by a second search tool with every flag it has, and by a walk that read every byte; all three found the plaintext file beside it. Scanning the message and the subject closes two real surfaces and leaves history out of reach, which a procedure should say. An agent shell's grep may also honour ignore files on a recursive walk, so what gets scanned should be named files.
A repository-local identity does not cover a commit made in a browser. A placeholder commit address works against what it is chosen to prevent: a shared address carrying a real name and a numeric id across hosts. A commit made through a forge's web UI is signed with the account's own email, because the browser cannot consult a repository-local config; neither can a second clone predating the convention. Listing every distinct author email is worth doing early: one often turns up among a repository's first commits, and by then rewriting history the other side has pulled is worse than the leak.
What is only a rule
Most checks fail loudly, which makes them mechanisms -- part 2. The human review and the identifier scan do not; they hold only because whoever follows the procedure honours them -- the shape that already failed twice. Which kind a step is, and when to convert one into the other, is rules and mechanisms.
A scan over a channel repository always returns hits, some entirely correct. It does not exist to return zero. It exists to make an exposure a decision instead of an accident.