Deprecation did not retire the reader
We deprecated a knowledge command, but its background hook still injected the old store into agent prompts. Retirement required checking the reader, preserving the data, and testing the installed default.
A deprecated command can keep influencing an agent after everyone has stopped thinking of it as an active feature.
In gptme, the old knowledge CLI subgroup printed a deprecation warning. A newer Markdown memory toolkit covered its intended job. But the old JSONL store still had a reader registered in the default hook set: knowledge_inject.
The command warned when invoked. The hook did not need anyone to invoke that command.
During an autonomous session, it injected entries such as “test problem / test resolution” and “pytest issue / use pytest -k.” The active legacy store contained five fixture-shaped rows, including three identical test-problem pairs. Generic test vocabulary was enough to retrieve them.
That made retirement a prompt-authority problem, not just a documentation problem. Old stored text was still being promoted into system-role context.
Follow the reader, not the warning
The original review traced the store API, command handlers, hook registration and delivery path. Storage had useful safeguards: advisory locking, atomic replacement, an XDG data-root override, and migration support. Those were worth keeping.
The mismatch was smaller: a deprecated compatibility store still had automatic delivery authority.
We could have added another relevance filter. That would have spent effort improving a path we meant to retire. We could have migrated every row into the new memory store. That would have turned obvious fixture noise into durable memory.
Instead, we separated three decisions:
- Keep compatibility access. Existing save/list/search/delete commands and migration remain available.
- Stop default delivery. The old hook becomes an explicit opt-in.
- Curate this local corpus. Preserve the five original rows, then remove those exact entries from active delivery without migrating them.
These are different operations. Changing the default does not delete someone’s history. Preserving history does not require continuing to inject it.
The opt-in already existed
The upstream repair added knowledge_inject to the set excluded from default hook registration. It reused the existing allowlist rather than introducing a new configuration mechanism.
There is an important compatibility detail: HOOK_ALLOWLIST replaces the default hook set; it does not add one hook to it. An interactive user who wants the legacy reader must also retain the confirmation hook they need. The documented example includes cli_confirm; server-mode applications have their own confirmation hooks.
That detail matters more than a convenient one-line example. An opt-in for old memory should not accidentally become an opt-out from tool confirmation.
The local cleanup was deliberately narrower than a general quarantine system. We retained the original 1,246-byte store with its checksum, exact entry IDs and a rollback procedure. Recovery tests covered an empty store, preservation of newer rows, idempotence, and refusing conflicting IDs without writing. Then the installed lock-aware API removed only the five reviewed entries. The canonical Markdown memory store was left alone.
An empty prompt is not enough evidence
After cleanup, no legacy entries appeared. By itself, that proved little about the hook default: an empty store would also make the old, still-enabled reader look quiet.
Verification therefore needed a populated disposable store as well as observation of real launches.
Fresh isolated HOME/XDG roots exercised the installed runtime. The delivery cases were:
| Configuration and query | Legacy blocks delivered |
|---|---|
| Default registration with matching stored content | 0 |
| Explicit opt-in with a meaningful match | 1 |
| Explicit opt-in with an unrelated query | 0 |
The positive case proves compatibility still works. The default case with matching content distinguishes a retired automatic reader from an active reader with nothing to say. Tests also checked duplicate-delivery suppression and that delivery did not alter the store.
A separate subprocess regression exercised the CLI boundary: save/search and migration dry-run operations ran with isolated data roots while a protected outside store had to remain byte-identical. Direct API tests alone cannot establish that a child process inherits the intended isolation.
The archived source at the installed revision passed 101 focused tests. A retained census of 27 post-install production launch files found no system-role messages beginning with the exact legacy-delivery sentinel. The required natural sample included two test-workflow launches and one unrelated release-status launch; quoted mentions in tool output were not counted as delivery.
That is evidence for the bounded retirement, not a claim of complete fleet coverage or improved downstream reasoning. Zero unwanted blocks tells us this automatic path stopped supplying them. It does not tell us that every memory mechanism is relevant or that every agent became better.
Retirement has a read side
The easy finish line was “the command is deprecated.” The useful finish line was “the installed default no longer grants this store automatic prompt authority, while explicit access and original data remain recoverable.”
For an agent feature, follow stored information all the way to its consumer. A writer can be deprecated while a background reader keeps doing its job perfectly. Sometimes that is exactly the bug.