Claude Code is a fast, careful engineer with no memory. Every session starts from zero. It doesn't know the rule the team agreed on last month, the deploy that broke on Tuesday, or why one folder is “special”. So it does the reasonable thing, and the reasonable thing is sometimes the exact mistake you already fixed.
We build Memmo with Claude Code every day, so we hit this constantly. Here is what we do about it, with real bugs from our own repo.
Two mistakes that tried to come back
The CLI that shipped without its code. Our CLI is published to npm. One release installed fine and did nothing: the package had no compiled dist/ folder. The cause was a missing .npmignore. Without one, npm falls back to .gitignore, which ignores dist/, even when package.json lists the files to ship. Deleting a file that looks redundant is exactly what a tidy agent would do.
The guide that hijacked finished projects. In September, users who had finished setup were thrown back into the onboarding guide. A “stay on the guide” flag never expired. The fix was small. Keeping it fixed is the hard part, because the next agent to touch onboarding has no idea that flag must expire.
Neither lesson belongs in a README, and neither fits on one line of CLAUDE.md that the agent reads whole on every session, whatever it is working on. What the agent needs is the right lesson, at the moment it touches the code the lesson is about.
Four moments where the agent gets the team's memory
memmo init connects a repo in one command. It adds Memmo as an MCP server and installs four Claude Code hooks. Each hook hands the agent a different slice of what the team knows.
npx @memmo/cli init- Session start: a briefing. A short summary of the repo's rules, architecture, key commands and known risks. Short on purpose, so it doesn't crowd out the task.
- Each prompt: recall for the task. When you ask for something, Memmo searches the approved memory for what's relevant to that request and adds it as context. Ask about deploys and you get the deploy gotchas, not the testing conventions.
- Before an edit: risk warnings. Right before Claude Code edits or writes a file, Memmo checks for risks and past failures tied to that path. Touch the CLI's packaging and the agent is told, before it changes anything:
CLI .npmignore required to ship dist/. Without it, npm fell back to .gitignore and packed a broken tarball despite the files allowlist. Keep .npmignore.
- Session end: learning. When the session ends, what happened (the task, the corrections you made, the errors hit) is turned into proposed memories. That is how the onboarding fix became a rule: “the onboarding guide must never gate a project that is already set up; the stay flag expires after 15 minutes”.
Hooks are silent and fail open. If Memmo is unreachable, the session carries on as if it weren't installed.
Nothing reaches an agent until a person approves it
Memory that writes itself is also memory that can be wrong. So every proposal lands in an inbox, and a person approves, edits or rejects it, the way you review code. Only approved memories are ever served to an agent.
When a memory turns out to be wrong, it isn't edited in place. A correction is proposed that supersedes it, and approving the correction archives the original. The history stays, so no future agent “fixes” things back to the old way.
Why not just a bigger CLAUDE.md?
Keep your CLAUDE.md. It's the right place for a page of stable conventions, and Memmo writes its own section into it. But a file is read whole every time, for every task. It belongs to one repo and one tool, and someone has to remember to update it. A team's memory is bigger than a page, changes every week, and should come back scoped to the file you are about to change. We compare the options in detail on Why Memmo.
What changed for us
Since those two lessons became memories, every agent that touches the CLI's packaging or the onboarding gate is told about them first. Not because the agent got smarter, but because the lesson is in front of it exactly when it matters. The same memory also feeds our pull request reviews, which is the subject of the next post.