Launching today
MemoryCustodian
Repo-native memory for coding agents
40 followers
Repo-native memory for coding agents
40 followers
MemoryCustodian gives Codex, Claude Code, Gemini, and other coding agents durable project memory—without a hosted service or bloating every prompt. Decisions, constraints, rejected approaches, and project context live as plain Markdown in your repo, where they can be reviewed, versioned, shared, and deleted like code. A manifest loads only the memory relevant to each task. Open source, local-first, and cross-agent.
MemoryCustodian
Hey Product Hunt 👋
I built MemoryCustodian because coding agents are increasingly capable, but every new session still tends to forget why a project looks the way it does.
Important decisions, constraints, rejected approaches, and repeated corrections often live only in old conversations—or get copied into increasingly large instruction files.
MemoryCustodian takes a different approach: durable project memory lives as plain Markdown inside the repository.
A small manifest tells the agent which memory files are relevant to the current task, so the memory can grow without forcing every session to load the entire project history.
What makes it different:
Repo-native and plain text—no opaque memory database
Reviewable, versioned, and shareable through normal Git workflows
Selective loading instead of injecting all memory into every prompt
Explicit support for updating, correcting, and safely forgetting memory
Works with Codex, Claude Code, Gemini, and generic coding-agent workflows
Free, open source, and local-first
The repository also includes a reproducible NightNotes demo showing a new agent session recovering an existing architectural decision and avoiding an already-rejected implementation path.
I’d especially love feedback on the memory structure, cross-agent workflow, and whether the installation experience feels simple enough for real projects.
Thanks for checking it out!
the "manifest loads only the memory relevant to each task" line is the part I'd poke at. relevance selection is its own hard problem - if it's simple keyword or path matching against the task description that's predictable, but if the agent itself is judging which memory files matter for the current task, you can end up with the same failure mode you're trying to avoid: it just won't load the one constraint file it doesn't realize is relevant, and you get no error, just quietly wrong behavior. how does the manifest decide relevance today, and is there any way to see what got left out for a given task
MemoryCustodian
@galdayan
That’s a fair concern. Today, the manifest is not doing semantic retrieval, keyword search, or relevance scoring.
The agent first classifies the task into a small category such as planning, implementation, artifact work, or maintenance. The manifest then deterministically maps that category to a fixed set of files. For example, planning and implementation load decisions.md, constraints.md, and do-not-use.md by default, so the agent does not judge individual constraints one by one.
There is still an agent-judgment boundary for selecting the task category and matching optional rules/, profiles/, or areas/. A wrong classification can therefore omit scoped memory, and we consider that a real limitation.
You can inspect the selected context with:
It shows what was loaded, while the full output also reports missing files and entries omitted by context budgets. What v0.9.1 does not yet provide is a complete trace listing every excluded module and why.
A more precise description would be: the manifest routes a bounded context pack through explicit, project-defined task categories.