Memorix: A Local-First Shared Memory Layer for Coding Agents via MCP

The Problem: Project Knowledge Trapped in Individual Chat Sessions

Every coding agent session starts cold. The previous session may have worked out why a module is structured a certain way, which migration is half-finished, or which approach was tried and abandoned, and none of that survives into the next chat. Switch from Claude Code to Codex mid-task and the loss is total: the new agent has no access to what the old one learned. Static rule files such as AGENTS.md or .cursorrules help, but they are written by hand and drift as the project changes.

Memorix targets exactly this gap. Its README frames the use case as re-explaining the same project to a new agent session, or a design decision being buried in a chat that cannot be found again. The intended user is a developer who works across more than one agent or IDE on the same repository and wants the accumulated context to live with the code rather than inside one vendor's chat history.

The scope is deliberately project-scoped. Memory is tied to the current Git project, which means a memory written while working in Cursor is visible to a Codex session opened in the same checkout. That is the core promise, and it is narrower than a general personal knowledge base.

Architecture: SQLite as Canonical Store, Rebuildable Indexes on Top

The README is explicit that Memorix is local-first and that SQLite is the canonical store. Retrieval is layered. Small projects use an in-process Orama path. Larger projects use a persistent SQLite FTS5 candidate index and, when available, an optional local LanceDB semantic shadow index. The README states that both indexes are rebuildable and that they are never a limit on how many durable memories can be kept. LLM-backed memory formation and embedding are optional rather than required.

That split matters for anyone evaluating the tool. The durable data is in SQLite, so the search layer can be thrown away and regenerated without losing memories. It also means the system degrades rather than fails: without an embedding model, keyword search over FTS5 still works. The trade-off is that semantic recall quality depends on whether the optional LanceDB path is configured, and the README does not quantify the difference.

Above the store sits a set of named memory types. Observation Memory holds searchable facts, fixes, gotchas, session summaries and implementation notes. Curated Long-term Memory holds reviewed episodic, semantic and procedural items with source evidence, and the README notes that only an explicitly portable user item can cross local projects. Reasoning Memory stores design rationale with alternatives and trade-offs. Git Memory derives engineering facts from commits. These are distinct stores with distinct entry points, not one undifferentiated blob.

Getting It Running: setup, doctor and the context commands

The README documents a per-agent setup path. The command is `memorix setup --agent <agent>`, and the README says it installs MCP configuration, rules, hooks, skills, plugins, bundles or extensions depending on which agent you name. Because the integration surface differs per agent, the same command produces different artifacts for Claude Code than it does for Cursor or Gemini CLI.

After setup, two commands are worth knowing. `memorix doctor agents` checks whether agent MCP config and guidance are current. `memorix repair agents` fixes Memorix-owned entries when they are not. This pair exists because agent config formats change and hand-edited entries get overwritten; the repair command is scoped to entries Memorix itself owns, which is a sensible boundary.

For day-to-day use, the README lists `memorix context "..." --brief-json` and `memorix resume "..." --brief-json`, plus the `memorix_project_context` MCP tool. The README describes the output as a bounded task Workset containing start files, current memory, source-backed knowledge, workflow starts, cautions and verification, with compact JSON receipts to keep fallback CLI use bounded. Other entry points named in the README include `memorix memory`, `memorix memory long-term`, `memorix reasoning`, `memorix knowledge`, `memorix knowledge workflow`, `memorix codegraph status|refresh|init|sync`, `memorix ingest commit`, `memorix hooks`, `memorix skills` and `memorix orchestrate`. The README does not print full install instructions in the excerpt available here, so the exact npm invocation and any global install step should be read from the repository before you start.

Code Memory Is Honest About Language Coverage

One of the more interesting details is how Memorix handles code understanding. The README describes versioned local code snapshots, source-backed TypeScript and JavaScript symbols and relations, file and symbol links, and freshness checks. For other languages it says the system keeps what it calls the honest Lite fallback. An already-indexed local CodeGraph or SCIP result can add a bounded external outline without taking over the local index.

That is a real constraint stated plainly rather than hidden. If your repository is primarily Go, Rust or Java, the symbol-level code memory is not the same product as it is for a TypeScript codebase. You get the fallback, and you can attach an external SCIP index if you already produce one, but Memorix will not build that index for you. Given that the project itself is written in TypeScript, this is a reasonable place to draw the line, but it does mean the feature table is not uniform across stacks.

The same pattern shows up in the indexing layer. LanceDB semantic search is optional and local. Projects that want it need to configure it; projects that do not get FTS5. The README does not describe an automatic fallback that detects quality degradation and warns you, so the difference between the two paths is something you would need to measure on your own repository.

Orchestration and the Multi-Agent Coordination Claim

The README lists `memorix orchestrate` as coordinating task context, handoffs, locks, verification and review loops for parallel agent work. That is a much larger claim than memory storage. Locks and verification imply that Memorix is mediating between concurrent agents, not just recording what they did.

The README does not explain the locking mechanism, what happens when an agent dies holding a lock, or how verification is decided. Those are the questions that determine whether orchestration is usable in practice or is a feature that works in the happy path. Until the documentation covers failure handling for concurrent writers, treating `memorix orchestrate` as production-ready for parallel agents is a leap.

There is also a governance detail worth noting in the Knowledge Workspace. The README says reviewed pages are protected: proposals never overwrite reviewed pages silently. That is a deliberate choice in favor of review gates over automatic updates, and it means knowledge does not silently mutate under you. The cost is that someone has to review proposals, which is manual work the tool does not remove.

A Real Alternative: Hand-Written Agent Rule Files

The obvious alternative is the approach most teams already use: a checked-in markdown file such as AGENTS.md or a per-tool rules file, read by the agent at the start of each session. The difference in approach is fundamental. A rule file is static, human-authored and identical for every session. Memorix is dynamic, machine-written from observed work, and queryable rather than read whole.

That difference cuts both ways. A rule file is trivially reviewable in a pull request, has no runtime dependency, and cannot corrupt anything. Memorix adds a SQLite database, an MCP server process, per-agent configuration that can go stale, and an indexing layer. In exchange you get retrieval: an agent can ask for context relevant to a specific task instead of loading a fixed document, and Git Memory can surface facts from commits that nobody would have written into a rules file by hand.

For a solo developer on a small repository, the rule file is probably enough. The case for Memorix strengthens with repository size, with the number of agents in rotation, and with how often the same context has to be re-established. The README's own framing supports this: the trigger is repeatedly re-explaining the same project, or an IDE that cannot see what another IDE learned.

Licence, Maintenance and What to Verify

Memorix is Apache-2.0, which permits commercial use, modification and redistribution provided the licence and notices are preserved and any modified files carry prominent change notices. It also includes an explicit patent grant. This is a permissive licence, and it is a different posture from copyleft alternatives; nothing here constitutes legal advice, and if you plan to redistribute a modified Memorix inside a product, read the licence text and your own counsel's guidance.

The release cadence visible in the repository is fast: v1.8.9, v1.9.0 and v1.9.1 all landed within roughly three days in early September 2026. Frequent minor releases on a memory system mean schema or index format changes are plausible, and the README does not describe a migration policy for the SQLite store. Before depending on it, check whether the store format is versioned and what happens to existing memories on upgrade.

The README also points to ACTIVE_WORK.md as the repository's single living work tracker for maintainer status and the public work boundary. That file is where the project states what is currently in scope. Read it before filing issues or planning around a feature, and verify the npm package name and current install command directly from the repository, since the excerpt available here does not include the full install section.

Editorial conclusion

Adopt Memorix if you routinely switch between Claude Code, Codex, Cursor or other MCP-capable agents on the same Git repository and keep re-explaining the same context. Do not adopt it if your work stays inside a single agent session, or if you need memory shared across machines without a Git remote in the loop. Before committing, verify that `memorix setup --agent <agent>` writes the MCP entry your agent actually reads, run `memorix doctor agents` to confirm the config is current, and check the SQLite store location so you know what ends up in your repository.

Official sources

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