A test that finds no sensitive digits in stored notes sounds reassuring. In Headlong’s public review, it was reassuring for the wrong reason: the test supplied empty conversation history, so the notes writer exited before it wrote a note.
The assertion would have passed even if the redaction filter had been removed. The repair, merged September 22 in PR #133, is a useful example of agent-assisted engineering judged by what the test can catch, rather than by its green result.
The copies were the problem
Headlong is an experimental persistent-agent harness whose thought stream continues between messages. Its public patch description reports that card details supplied in chat had been repeated by the responder, then carried into summary blocks. The problem was not confined to the outgoing answer: observations, deferred-work requests and person notes created additional copies.
The responder implementation applies a shared filter to those restatements. It deliberately retains the original inbound record, and the model still receives the raw input. This reduces repeated sensitive text; it is not an erasure system or proof that the model never sees it.
Review found four failure exits still quoting the original message: timeout, exhausted output budget, broken JSON and a raw action-object response. It also found an ordering problem. Cutting a message to an excerpt before filtering could cut through a card-shaped number. The revised code filters once, then shortens the safe excerpt, and uses it across the observation paths.
A test needs something real to protect
The repaired shell suite supplies nonempty history and runs the notes writer in the foreground. It checks that a memory file exists, that useful ordinary text survived, that a redaction marker appears and that the synthetic sensitive digits do not.
Then comes the control: the suite runs a copy with the notes redaction pipe removed. This time the same write stores the digits. The pair establishes that the protected operation ran and that the filter changed its outcome. A test that merely sees no bad output cannot establish either fact.
Portability mattered too. An earlier expression used a word-boundary escape that did not behave as intended under stock macOS sed. The final filter uses explicit POSIX character boundaries, and a further revision replaced a GNU-style in-place edit in the test’s control setup. A broken test mutation can produce false confidence just as easily as a broken production filter.
A transferable skill: prove the write, then break the guard
For a redaction or authorization test, first assert that the intended operation occurred. Give it useful content that must survive. Assert the protected result. Finally, remove or bypass the guard in an isolated control and require the forbidden outcome to become observable. Exercise failure exits as well as the normal return: error explanations often repeat the input they are explaining.
We ran Headlong’s focused suite on the inspected checkout: 29 checks passed, including the real notes write, the filter-removed control and four failure paths. The suite stubs model and chat calls; this was not a live service test, a macOS rerun or an audit of every data path. Pattern-based redaction also leaves both misses and overmatching to test.
The project’s public coding-agent design explicitly says Codex has already been used; its backoff design credits independent Claude and Codex drafts. That establishes agent use in the project, not which model wrote this patch or how much time it saved.
The lesson is smaller and more durable than an authorship claim: before celebrating that a system stored no forbidden data, establish that it stored anything at all.