# Memorix: a local-first memory layer shared by Claude Code, Codex and Cursor

> Memorix keeps one searchable project memory under your Git project and exposes it to any MCP-capable coding agent. The design is local-first and the optional parts are genuinely optional, but the setup surface is wide.

**AVIDS2/memorix** — Open-source cross-agent memory layer for coding agents via MCP. Compatible with Claude Code, Codex, Cursor, Windsurf, Gemini CLI, Antigravity, OpenClaw, Hermes Agent, Oh-my-Pi, Pi, Copilot, Kiro, OpenCode, and Trae.

- Repository: https://github.com/AVIDS2/memorix
- Website: https://mem.rglens.com
- Stars: 807 · Forks: 65
- Language: TypeScript
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/avids2-memorix

## The problem Memorix targets: memory trapped inside one chat window

The README frames the problem in a way most people who use coding agents will recognise. A session figures something out, the chat ends, and the next session starts from zero. Switch from Claude Code to Cursor and the second tool has no idea what the first one established. Git records what changed in the code, but it does not record why, and agents cannot query commit history as engineering facts on their own. Memorix is aimed at developers who run more than one agent against the same repository and are tired of restating architecture decisions, gotchas and fixes. The README states the memory lives under the Git project rather than inside one chat window or one tool, so the agent can change while the project memory stays. That is a narrower and more honest pitch than "AI memory" in general: it is project-scoped, not personal. If you only ever use one agent in one long session, the value proposition mostly evaporates.

## How the memory layer is structured, and what actually stores the data

The README is explicit that SQLite is the canonical store and that the project is local-first. Retrieval is tiered. 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 both indexes are rebuildable and are never a limit on how many durable memories you can keep, which matters if you worry about a search index becoming the ceiling on stored knowledge. LLM-backed formation and embedding are optional. On top of the store sit several distinct memory types: Observation Memory for facts, fixes, gotchas and session summaries; Curated Long-term Memory for reviewed episodic, semantic and procedural items with source evidence; Git Memory, which turns commits into searchable engineering facts; and Reasoning Memory for design rationale, alternatives and trade-offs. Code State and Code Memory adds versioned local code snapshots with source-backed TypeScript and JavaScript symbols and relations. The README is candid that other languages keep a "Lite" fallback rather than pretending to full symbol coverage. That is the kind of boundary worth trusting.

## Installing Memorix and wiring it to one agent

The package is published on npm as memorix, and package.json declares two binaries: memorix and memcode. The README points to memorix init for interactive generation of configuration, and memorix setup --agent <agent> as the single setup path for MCP, rules, hooks, skills, plugins, bundles or extensions depending on the agent. The .env.example file says secrets go in .env and behaviour settings go in memorix.yml, and that memorix init generates both. Start there.

```bash
memorix init
memorix setup --agent <agent>
```

After setup, the agent should see the Memorix MCP server in its configuration. The repository ships example configs under examples/, including examples/claude-desktop-config.json, examples/cursor-mcp.json and examples/windsurf-mcp.json, which are the reference for how each client expects the server entry to look. To check that the wiring is current, the README documents a doctor command that inspects agent MCP config and guidance and a repair command that fixes Memorix-owned entries.

```bash
memorix doctor agents
memorix repair agents
```

The README also documents a bounded context call that returns a compact JSON receipt rather than a large dump, which is the intended first real use: ask what the project currently knows before starting work.

```bash
memorix context "..." --brief-json
```

If you prefer containers, compose.yaml builds the local image, maps port 3211, sets MEMORIX_PROJECT_ROOT to /workspace and MEMORIX_DATA_DIR to /data/.memorix/data, and defines a healthcheck against http://127.0.0.1:3211/health. The comment in that file notes the default HTTP MCP session timeout is 30 minutes and raises it to 86400000 ms for long IDE work blocks.

## Where Memorix gets in the way

The setup surface is the first real cost. Memorix does not just register an MCP server; it installs rules, hooks, skills, plugins or extensions depending on the agent, which is why memorix doctor agents and memorix repair agents exist at all. Anything that writes into another tool's configuration needs a repair path, and the presence of one tells you the maintainers expect drift. Second, the language coverage is uneven by design. Code Memory is described as source-backed for TypeScript and JavaScript, with a Lite fallback elsewhere, so a Python or Go repository will not get the same symbol-level context. Third, the retrieval stack has three layers (Orama, SQLite FTS5, optional LanceDB) and the README does not document rollback for index rebuilds or migrations. If you need a documented downgrade path before upgrading, that documentation is not in the README. Fourth, this is the wrong tool for a solo developer in a single agent. The whole value is cross-agent and cross-session continuity; without that, you are adding a process, a data directory and a config surface for nothing.

## Memorix compared with plain rule files and hand-written context docs

The obvious alternative is the pattern most teams already use: a CLAUDE.md or AGENTS.md file checked into the repository, plus a few Markdown docs describing architecture. That approach is portable, has no runtime, and any agent can read it. The README names the trade-off directly under "Static rule files drift": gotchas and fixes evolve from real work, and a hand-maintained file does not. Memorix instead derives memory from sessions, commits and explicit reasoning entries, and keeps it in SQLite under the project. The difference in approach is that a rule file is authored once and read many times, while Memorix is written continuously and queried on demand. The cost is that you now depend on a running component and a local database, and the content of your memory is only as good as what the agents recorded. A team that already maintains a disciplined AGENTS.md and reviews it in pull requests is not obviously better off switching.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10, which is recent. Releases are frequent: v1.9.1 on 2026-09-08, v1.9.0 on 2026-09-07, v1.8.9 on 2026-09-06, and package.json already lists version 1.9.3. That cadence is a real maintenance cost for adopters, not just a sign of health. Frequent minor releases mean the agent setup files, the MCP entry and the on-disk schema are all moving. The README points to ACTIVE_WORK.md as the repository's single living work tracker for maintainer status and the current public work boundary, which is the file to read before pinning a version. The licence is Apache-2.0, a permissive licence that permits commercial use and modification and includes an explicit patent grant; it also requires that you preserve notices and state significant changes. That is a summary, not legal advice, and if you redistribute Memorix inside a product you should have counsel read the LICENSE file rather than this paragraph. Note that the npm package metadata and the repository package.json are separate sources of truth for the version you actually install.

## Conclusion

Adopt Memorix if you switch between Claude Code, Codex, Cursor and similar agents on the same repository and keep re-explaining the same decisions. Skip it if you work in a single agent, single session, or if your team cannot add a new process to every developer machine. Before rolling it out, run memorix setup --agent for one agent, confirm the SQLite store lands where you expect, and read ACTIVE_WORK.md, which the README calls the repository's single living work tracker.

## FAQ

### What is Memorix?

Memorix is a local-first shared memory layer for AI coding agents, distributed as the npm package memorix. It stores project memory in SQLite and exposes it to MCP-capable agents such as Claude Code, Codex, Cursor and Windsurf.

### Which coding agents does Memorix work with?

The README lists Claude Code, Codex, CodeBuddy Code, Cursor, Windsurf, Copilot, Gemini CLI, OpenCode, Grok Build, OpenClaw, Hermes Agent, Oh-my-Pi, Pi, Kiro, Antigravity, Trae, DeepSeek Harness and WorkBuddy, plus any MCP-capable agent. Setup uses memorix setup --agent <agent>.

### How do I install Memorix and connect it to my agent?

The package is published on npm as memorix. The README documents memorix init for interactive generation of .env and memorix.yml, then memorix setup --agent <agent> to install the MCP, rules, hooks, skills or plugin integration for that agent.

### Does Memorix store my memory in the cloud?

The README describes Memorix as local-first with SQLite as the canonical store, and the container configuration keeps data in a volume under /data/.memorix/data. LLM-backed formation and embedding are optional, so an external API key is only needed if you enable those.

## Sources

- [AVIDS2/memorix on GitHub](https://github.com/AVIDS2/memorix)
- [License: Apache-2.0](https://github.com/AVIDS2/memorix/blob/main/LICENSE)
- [Project website](https://mem.rglens.com)
- [README](https://github.com/AVIDS2/memorix/blob/main/README.md)
- [Releases](https://github.com/AVIDS2/memorix/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/avids2-memorix