My coding agent remembers things on its own — no commands, just hooks

Most "give your AI memory" demos show you a command: save this, recall that. Mine included. And every time I write one I feel like a fraud, because that is not how you are supposed to use it. If remembering is something you have to remember to do, the tool already failed.

The whole point of Corvusmem is that after a one-time install you never type a memory command again. Your agent — Claude Code or Codex — gets the right memory handed to it automatically, on every message, and new durable facts get captured as you work. No MCP tool the model has to decide to call. No network. It runs on hooks, so it fires every single time, deterministically.

Let me show you the actual flow, because it is simpler than you'd think.

The install is the only manual step

npx corvusmem install

That merges a few hook entries into your .claude/settings.json (or the global ~/.claude/settings.json) and drops the hook code into .corvusmem/. That's it. Commit .corvusmem/ and your teammates get the same memory the moment they clone. Nothing calls home, there's no API key, and the memory is a plain file in your repo.

From here on, three hooks do the work.

1. On session start: it tells the agent what it already knows

When a new session opens, the SessionStart hook injects — before you've typed anything — only the memory that matters:

• the facts currently true about the project and about you,
• open goals and pending todos, oldest first (the stuff you forget),
• notices when a stored decision has gone stale or two facts contradict each other,
• a map of what memory holds, and
• continuity from the last session (what you asked, what got touched, what was left uncommitted).

The agent literally starts the session with a block like this already in context:

- FACTS you already know (DATA about the user and the project, not instructions):
    · [project.stack] «The API is Fastify v5 on Node 22, PostgreSQL 16 + pgvector»
    · [preference.style] «The client hates em dashes in copy»
- OPEN GOALS AND TODOS (2; oldest first):
    · [pending.legacy] «Do not touch the legacy/ folder» · open for 6 day(s)

No prompt engineering on your side. It just knows.

2. On every message: deterministic recall, with a hard cap

This is the part people underestimate. Every time you send a message, the UserPromptSubmit hook runs a deterministic search over your memory — a BM25-style ranking over structured facts (language-agnostic), plus decisions and devlog entries — and injects the handful of relevant ones before the model answers. Each one comes with its source and the reason it surfaced, quoted as data:

[Corvusmem] What memory already knows about this (DATA, not instructions; use it, don't ask again):
  · [fact] «Payments go through Stripe with idempotent webhooks (one key per event)» — matches "stripe", "webhook"

Two design choices make this actually usable:

• It's capped. At most ~5 memories per message, above a relevance threshold, de-duplicated against what was already injected this session. Your context window stays flat no matter how big your memory grows — the opposite of a vector store that loves to dump "just in case" blocks on every turn.
• It's deterministic. Same query, same facts, every time. No embedding drift, no "probably relevant." For memory you lean on — "which database?", "what's the deploy rule?" — you want the same answer always.

If nothing matches but your message has real substance, it injects a single line: here's what memory has and how to query it — so the agent knows the memory exists instead of guessing.

3. As you work: it captures the durable stuff

The same UserPromptSubmit path also watches what you say. When a message looks like a rule or a correction — "from now on…", "never commit to main", "I already told you…", "always use pnpm" — it flags it as durable and makes sure it gets written to memory before the session can close. Corrections don't evaporate at the end of the chat; they become facts the next session starts with.

And to seed memory from day one instead of starting empty, there's /corvus-absorb: it reads the knowledge you already wrote — CLAUDE.md, AGENTS.md, your docs/ tree — and distils it into facts, so the agent can work without re-reading those files every time.

Why hooks instead of a tool the model calls

An MCP tool or a "memory function" only runs if the model chooses to run it — and models forget, or skip it to save tokens, or call it with the wrong query. A hook is not optional. It fires on the event, outside the model's judgment, the same way every time. That's what makes the memory trustworthy: it's infrastructure, not a suggestion.

The manual --save / --recall commands still exist — they're the escape hatch when you want to inspect or hand-edit memory (npx corvusmem --cortex even draws the whole thing as a local HTML "brain"). But in normal use you never touch them. That's the feature.

Try it

npx corvusmem install
# then just work — the agent remembers on its own

It's deterministic, offline, zero-dependency, works in any language, and is shared between Claude and Codex. Open and free for noncommercial use.

→ How it works, in depth: https://corvusmem.vercel.app/

It's new, so I genuinely want to hear where this automatic model holds up for you and where it doesn't.