OwnMem: Git-Native Memory for AI Coding Agents, Reviewed

The problem OwnMem attacks: memory nobody can review

Agent memory products usually compete on how much they remember. OwnMem starts from the opposite question, stated in its README: who owns project knowledge, who may change it, and how can a bad memory be stopped before it changes a coding agent's actions. That framing tells you who this is for. It is for teams running Claude Code, Codex, Cursor, Gemini CLI or Grok CLI on a shared codebase, where an agent's accumulated notes have started to function as undocumented policy. A wrong note about a build flag or a deprecated API does not just mislead one session; it propagates into every later session that retrieves it.

The design answer is ownership. Memory lives as readable Markdown in .ownmem/ and travels through clone, review and rollback with the code. A memory change is a commit, so it can be reviewed like any other change and reverted like any other change. That is a deliberate cost: someone has to read the diffs. The project's own comparison table is candid that most systems optimize for remembering more, and OwnMem optimizes for being able to stop a memory before it acts.

How the compile and recall pipeline actually works

OwnMem separates writing memory from delivering it. The repository holds three layers of Markdown: L1 routing, L2 area indexes and L3 topics. Trust receipts live outside the text they authorize, so content cannot declare itself trusted. Schema, graph, lifecycle and evidence gates then compile that material into a content-addressed immutable snapshot, which is what the runtime reads. The point of compiling is that recall never rereads prose that may have changed mid-query; the same query, config and snapshot produce the same ranking.

Retrieval runs five deterministic candidate lanes locally: exact, BM25F, n-gram, fuzzy and graph, fused without a model or network call. Embeddings exist as an optional sixth lane but stay at weight 0 until local A/B evidence passes, which is a conservative default worth noting. Before anything reaches an agent, four independent gates run: relevance, epistemic validity, task applicability and action risk. Their outcomes are normal delivery, advisory, quarantine or abstention, all under a context budget. Insufficient evidence produces silence rather than invented confidence.

Evolution is bounded in the same spirit. An end-of-turn coordinator may promote only replay-proven, quota-bounded, precisely reversible R0 retrieval metadata without a human. Everything at R1 through R5 becomes review material. Promotion requires proving a baseline miss, candidate-only recovery, and zero regression on the previously passing corpus. Automatic edits carry a verified inverse operation, so a failure restores the exact previous bytes.

Installing OwnMem and getting a first memory into the repository

OwnMem ships as an npm package and requires Node.js 20.6 or newer. Run it inside the repository that should own the memory, not in a global location. The README's quick start installs it as a dev dependency and then initializes the layout:

npm install --save-dev ownmem
npx ownmem init --locale auto --hosts claude,codex,grok --layers dashboard --hook

The init command creates .ownmem/ and edits only managed marker regions in host files, so your existing agent configuration is not rewritten wholesale. If you want to see what would change before committing to it, the README documents a dry run:

npx ownmem init --check

Narrow the adapters when you only use one host. The README gives --hosts claude, --hosts codex, --hosts cursor and --hosts gemini as the single-adapter forms. After initialization, reopen the agent. The hooks are what make the memory visible to the host, and they are also the most common place for a silent failure, covered below.

The command surface is exposed through the ownmem binary declared in package.json, so npx ownmem <subcommand> is the general shape. The README documents init, and the repository keeps schemas/ alongside lib/, which suggests the JSON shapes used by the compiled snapshot are published as part of the package exports.

Where OwnMem fails silently: host hook trust

The most concrete limitation in the README is not about retrieval at all. It is host trust. Claude Code and Grok CLI both read .claude/settings.json, but Grok additionally needs that folder trusted once, either by running /hooks-trust inside grok or by starting it with grok --trust. Without that step, the README states plainly that it silently runs none of these hooks. Silent is the operative word: nothing errors, the agent just never sees your memory.

Codex is stricter. It reads <project>/.codex/hooks.json behind three separate permissions: hooks = true under [features] in ~/.codex/config.toml, the project itself trusted, and the hook trust prompt on first sight. An untrusted project never discovers the file, and the README notes that neither --dangerously-bypass-hook-trust nor a -c projects... override reaches that layer. The hook process also runs at the project root with node_modules/.bin on PATH and the same JSON on stdin that Claude Code sends, but with no CODEX_* environment variable of any kind, so every command has to declare its host explicitly.

That is a real operational tax. A team that installs OwnMem and skips the trust step will conclude the tool does nothing. The README covers Claude Code, Grok and Codex in the visible portion; the passage on Cursor and Gemini CLI is truncated, so treat their setup as something to confirm against the repository's docs/ directory rather than assume.

OwnMem compared with embedding-first memory layers

The obvious alternative approach is a vector-store memory layer: chunk notes, embed them, retrieve by cosine similarity, and let a model write new memories freely. OwnMem's difference is not that it lacks embeddings, since an optional sixth lane exists, but that the lane sits at weight 0 until local A/B evidence passes. A vector-first system would have it on by default and would treat a high similarity score as sufficient reason to inject text.

OwnMem instead separates retrieval correctness from user-confirmed outcomes from agent self-attribution, keeping three ledgers that never impersonate one another. In a vector-first design those collapse into one store, and an agent's own confident summary can outrank a verified fact. OwnMem's four delivery gates exist precisely to prevent that: a candidate can be relevant and still be quarantined or abstained on if its evidence is weak or its action risk is high.

The trade-off runs the other way too. A vector-first layer needs no Markdown discipline, no schema, and no review step, and it will surface fuzzy conceptual matches that a BM25F and n-gram fusion may rank lower. OwnMem asks you to curate. If your team will not review .ownmem/ diffs, the governance machinery is overhead with no payoff.

Maintenance, release cadence and licence

The repository is not archived, and the last push was on 2026-09-09. Releases are close together: v0.6.0 on 2026-09-09, v0.5.5 on 2026-09-05 and v0.5.4 on 2026-09-03, all inside a single week. That cadence suggests active work, but it also means the 0.x surface is still moving, and the version number is honest about that. A team adopting OwnMem should expect to track releases rather than pin once.

Upgrade cost is partly bounded by the package's own scripts. The package.json defines npm test, npm run benchmark with --iterations 20, npm run benchmark:release with --iterations 100, and npm run verify:release, which chains the tests, the release benchmark and npm pack --dry-run --json. Those are the project's own gates, not a promise about your repository. The runtime dependency list is short: ajv and yaml. That matters for upgrade risk, because a small dependency surface is easier to audit than a retrieval stack that pulls in a model runtime.

The licence is Apache-2.0, declared in package.json and shipped with LICENSE and NOTICE files at the repository root. Apache-2.0 is permissive and includes an explicit patent grant and a NOTICE mechanism, which is friendlier to corporate use than a copyleft licence. Publishing uses provenance: true, so npm attestations are part of the release. None of this is legal advice; if your organization has a licence review process, the NOTICE file is the artifact it will want.

Editorial conclusion

Adopt OwnMem if memory for your coding agents is becoming an unreviewable artifact and you want it versioned, diffable and gated before it reaches an agent's context. Skip it if you want memory that learns aggressively on its own, or if your team will not maintain the Markdown it creates. Before rollout, verify that your host actually loads the hooks: run npx ownmem init --check, then confirm the managed marker regions in .claude/settings.json or .codex/hooks.json, and remember that Grok CLI needs /hooks-trust and Codex needs hooks = true under [features] before any of it runs.

Frequently asked questions

Official sources

1. grpcer/ownmem on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases