# marm-memory: a local SQLite memory server for Claude Code, Codex and Gemini

> marm-memory is an MCP server that keeps session history, codebase indexing and concept links in one local SQLite database. It is aimed at developers running several coding agents who want context to survive a client switch, and the trade-off is that everything lives in a single SQLite file you now have to look after.

**Lyellr88/marm-memory** — Local-first 3-in-1 AI memory layer & MCP server for Claude Code, Codex, Grok, Gemini, VS Code and Cursor. Fuses session history, codebase indexing & concept graphs in SQLite. Enables zero-cloud, privacy-first context & instant recall, supports multi-agent swarms.

- Repository: https://github.com/Lyellr88/marm-memory
- Website: https://lyellr88.github.io/marm-memory
- Stars: 409 · Forks: 86
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/lyellr88-marm-memory

## The problem marm-memory targets: context that dies with the chat window

Every MCP client keeps its own conversation state. Move from Claude Code to Codex, or start a new session after a long debugging run, and the decisions, fixes and research notes from the previous session are gone. The README states the pitch plainly: "Your AI forgets everything. MARM Memory doesn't." The intended user is a developer running more than one agent against the same project, or one agent across many sessions, who is tired of re-explaining the same architecture decisions.

The project bundles three things that are usually separate tools. Core Memory stores sessions, structured logs, notebooks, summaries and semantic memories. Code Graph indexes a repository so an agent can find symbols and follow code paths without rereading the whole tree. Concept Graph connects people, decisions, errors and ideas extracted from stored memories, and links them back to code where it can. All three sit in one SQLite database on your machine, which is the whole point: no cloud round trip, no vendor holding your project history.

## How the memory, code and concept layers actually fit together

The README describes three layers. The memory model holds sessions, structured logs, notebooks, summaries and semantic memories. The scale layer is SQLite in WAL mode with connection pooling, a serialized write queue and HTTP rate-limit presets, which is what lets one server handle a solo user and a multi-agent burst without corrupting writes. The intelligence layer adds an FTS filter, semantic re-rank, a bounded semantic fallback, auto-classification, write-time consolidation and compaction candidates.

That middle layer is the most interesting design choice. A serialized write queue means writes are ordered through one path rather than racing on the same SQLite file, and the rate-limit presets exist because HTTP clients can fire many tool calls at once. The cost is that heavy parallel indexing will queue rather than scale out; SQLite is the ceiling here, not the server process.

Indexing runs per repository. According to the README, pointing the tool at a repo creates an independent Code Graph that keeps itself current as you work, and you can explore it from Knowledge Graph, then Code Explorer, before storing a single memory. The Concept Graph is different: it builds itself as you store memories, so an empty memory store means an empty concept graph. The Console App shows Memories, the Knowledge Graph and Indexed Projects, including build progress for both graph types.

## Installing marm-memory and storing your first memory

The README gives a pip install followed by an init command that writes configuration for the agent profiles you name. Run both, and the init step targets your home directory unless you pass no flags, in which case it installs into the current project folder.

```bash
pip install marm-mcp-server
marm-memory init --g-claude --g-codex --g-gemini
```

The README also lists --g-qwen and --g-kiro as profile flags. After init, the project expects you to hand setup to the agent itself with the prompt "Use the marm-init skill to set up MARM." If you would rather wire it manually, start the server and register the HTTP endpoint with your client:

```bash
marm-memory start
claude mcp add --transport http marm-memory http://localhost:8001/mcp
```

The README notes that Codex uses a different form: codex mcp add marm-memory --url http://localhost:8001/mcp. For a fully local transport with no listening port, run marm-mcp-stdio and register it as a stdio server instead. Once the server is up, marm-memory console opens the local UI, and marm-memory fast-start-http starts the runtime, launches the console and opens it in your browser. Lifecycle commands are status, logs --follow, restart and stop.

## Where marm-memory is the wrong tool

SQLite is the single point of failure and the single point of contention. If several agents index large repositories at the same time, the serialized write queue turns that into waiting, not parallelism. The README's own scale layer exists because the database, not the network, is the bottleneck. Anyone expecting a memory server to absorb a whole engineering organisation's traffic should look elsewhere.

The Concept Graph is the weaker of the three layers. It is built from what you store, so its quality tracks the quality and volume of your memories. The README does not document a way to correct or prune bad links, and it does not describe rollback for a memory store that has accumulated wrong entries. Treat it as an index that grows, not as an analysis tool you can query with confidence.

There is also a client-support boundary worth checking before you commit. The README lists Claude Code, Codex, Grok, Gemini, VS Code and Cursor in the project description, but the concrete setup examples centre on claude, gemini, qwen and codex. If your client is not in that set, verify the transport works before you migrate any history into it.

## marm-memory compared with a hosted memory API

The obvious alternative is a hosted memory service exposed over MCP, where the vendor runs the database and you get retrieval quality without operating anything. The difference is not features, it is where the data sits and who pays for the retrieval work.

With a hosted service, your session history leaves the machine, and the retrieval model is whatever the vendor ships. With marm-memory, the database is a SQLite file on your disk, the server is a Python process you start and stop, and the recall pipeline is the local FTS filter plus semantic re-rank described in the README. You get privacy and offline operation, and in exchange you own backups, disk usage and upgrades. If your project history is sensitive, or your network is restricted, that trade is usually worth it. If your team already standardises on a cloud memory vendor and nobody cares where the notes live, marm-memory adds a process to babysit for no gain.

## Maintenance, releases and the Apache-2.0 licence

The repository is not archived and the last push was on 2026-09-10, so it is being worked on. The release cadence supports that: v2.47.0 landed on 2026-09-02, v2.46.2 on the same day, and v2.45.0 on 2026-08-29. The README header advertises v2.48.0 while the release list stops at v2.47.0, so expect the documentation and the packaged version to drift slightly between releases.

That cadence is also the upgrade cost. Frequent minor releases mean you should read CHANGELOG.md before pulling a new version, particularly if you have accumulated a large memory store. The README does not document a migration or rollback procedure for the SQLite database, so back up the file before upgrading. Nothing in the README describes a downgrade path.

The licence is Apache-2.0, which permits commercial use and modification with the usual notice and attribution conditions. The repository also carries NOTICE and THIRD_PARTY_NOTICES.md files, which matter if you redistribute the server inside a product. That is a packaging detail to check with whoever handles licensing on your side, not a legal opinion.

## Conclusion

Adopt marm-memory if you already switch between two or more MCP clients and want their context in one place you control. Skip it if you are happy with a single cloud memory service, or if you expect the Concept Graph to be a polished analysis tool rather than a link index that grows from what you store. Before committing, install it with pip, run marm-memory init, store a few real memories, and then open the console at http://localhost:8001 to check whether the Concept Graph links are useful on your own notes.

## FAQ

### What is marm-memory used for?

It gives AI coding agents a shared local memory so session history, repository structure and concept links survive between chats and between clients. The README frames it as a fix for context that normally gets lost when you switch from Claude Code to Codex or Gemini.

### How do I install marm-memory?

Install the package with pip install marm-mcp-server, then run marm-memory init with the profile flags for your clients, for example --g-claude --g-codex --g-gemini. Running init without flags installs into the current project folder instead of your home directory.

### Does marm-memory work over STDIO as well as HTTP?

Yes. The README lists HTTP as the default path on http://localhost:8001/mcp and offers marm-mcp-stdio for a private local STDIO setup, registered with your client using the stdio transport.

### What are the disadvantages of marm-memory?

Writes are serialized through a queue on top of SQLite, so concurrent indexing waits rather than scaling out, and the Concept Graph is only as good as the memories you store. The README does not document rollback or a way to prune bad concept links.

### Is marm-memory free to use?

The repository is licensed under Apache-2.0, which allows commercial use and modification under its notice and attribution conditions. The repository also includes NOTICE and THIRD_PARTY_NOTICES.md files that apply if you redistribute it.

## Sources

- [License: Apache-2.0](https://github.com/Lyellr88/marm-memory/blob/MARM-main/LICENSE)
- [Lyellr88/marm-memory on GitHub](https://github.com/Lyellr88/marm-memory)
- [Project website](https://lyellr88.github.io/marm-memory)
- [README](https://github.com/Lyellr88/marm-memory/blob/MARM-main/README.md)
- [Releases](https://github.com/Lyellr88/marm-memory/releases)

---

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