# memgit [Health: Active]

**Category:** 🧠 Knowledge & Memory  
**Repository:** https://github.com/code4161/memgit  
**GitHub Stars:** 4  
**npm Downloads (last month):** 1211  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/memgit

## Description
Git for AI memory — version-controlled, searchable context that persists across sessions

## Tools
Capabilities this server exposes over MCP:

- **resume_session** — Get a compact 'where we left off' digest: the status board (live entity state from tracker memories), the last checkpoints (most recent actions taken), staged work in flight, recently updated memories, critical rules that always apply, and a memory index of topics with counts. This is the authoritative record of what happened in previous sessions. Use your judgment about when the current request depends on that record: any ask that presupposes shared history — continuing work, referencing 'pending' or 'recent' things, resuming after a break — can't be answered correctly from the conversation or open files alone, however plausible they look. An open file shows what the user is looking at; this shows what was actually done last. Cheap to call, so prefer checking over assuming; skip it only when the request is clearly self-contained.
- **search_memories** — Search your persistent memory store for facts, rules, and lessons relevant to the current task. CALL THIS: at the start of every session, before answering questions about past work, before applying preferences the user may have expressed before, or whenever you are unsure whether you have prior context on a topic. SCOPED BY DEFAULT: results come from the current project's family plus global (project-less) memories — other projects' memories never appear unless you widen. To widen: pass all_projects=true to search the entire store (each hit then carries its 'project' label), or pass project=<label> to hard-filter to one specific project. The resume digest and <memgit-recall> blocks show a memory index with counts ('+N more on <topic>') — those topics are guaranteed to return results here; the injected blocks are a teaser of this store, not its full depth. Returns memories ranked by relevance — only what matters, not everything. Superseded (corrected/replaced) memories are hidden by default. This is faster and more relevant than reading individual memory files.
- **get_memory** — Fetch a single memory by its exact slug identifier. CALL THIS: when search_memories returned a relevant slug and you need the full details (why, when to apply, tags). Slugs are kebab-case identifiers like 'ig-pipeline-no-fallback' or 'trading-capital-track'.
- **list_memories** — List all memories, returning slug + rule for each. CALL THIS: to browse what's stored, discover memory slugs for get_memory, or audit the full memory set. For finding relevant memories on a topic, use search_memories instead — it is faster and ranked.
- **save_memory** — Persist a new fact, rule, preference, or lesson to the memory store for future sessions. CALL THIS: whenever you learn something the user would want you to remember next time — a preference they stated, a rule they corrected you on, a project decision, a lesson from a mistake, or a reference to an external system. Do NOT save ephemeral or task-specific details; save durable facts only. If a memory with the same slug already exists, this updates it — that is exactly how 'tr' trackers are meant to be updated when an entity's state changes. When this memory CORRECTS or replaces existing ones, pass their slugs in 'supersedes' instead of writing 'CORRECTED:' prefixes or leaving stale duplicates.
- **verify_memory** — Promote an UNVERIFIED (candidate) memory to trusted/committed after you have confirmed its content is a legitimate fact. Once verified, it can inject into high-authority context again. Use this to resolve the candidate/committed boundary in-session (the operator does not do it manually). Pass verified=false to demote a memory back to candidate.
- **get_checkpoint_log** — Show recent checkpoint history for the memory store — when memories were last synced and what changed. CALL THIS: to understand how fresh the memory store is, or to debug sync issues.

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "memgit": {
    "command": "npx",
    "args": ["-y","memgit-mcp"]
  }
}
```

## Documentation

## What memgit does

memgit gives AI assistants persistent context outside an individual chat session. Memories are stored as readable `.toon` files and organized in a content-addressed object store using SHA-256 identifiers. The data model includes memories, checkpoints, threads, and commits, providing a Git-like history for changes to stored context.

Search uses BM25 ranking to return the most relevant memories instead of loading the entire store. Memories can be associated with a project, and searches, recall injections, and resume information default to the current project family plus explicitly global memories. This helps keep context from unrelated repositories out of an active session.

## How it works

The command-line application initializes a store, manages memories, and exposes the store to AI tools through MCP. The documented `npx` configuration runs `memgit-mcp` without requiring a separate Python installation. The Python package and platform package options provide the full CLI.

`memgit init` selects a suitable store location and can offer to import existing Claude Code memories. `memgit setup` registers the server with supported AI tools, while `memgit setup hooks` installs Claude Code hooks for automatic session integration. The hooks can add a resume digest at session start, inject BM25 matches for prompts, surface path-related hints, enforce selected rules before tool use, and checkpoint markdown memories asynchronously.

For an existing repository, `memgit onboard` creates a bounded repository digest from Git history, changed files and directories, authors, branches, tags, manifests, and relevant documentation. That digest can guide an agent in extracting durable project facts into the store.

## Setup and configuration

Install with one of these supported approaches:

- `pip install memgit`
- `brew tap code4161/tap && brew install memgit` on macOS with Homebrew
- `choco install memgit` on Windows
- An MCP client configuration using `npx -y memgit-mcp`

After installation, run `memgit init`, then `memgit setup`. Use `memgit stats` to inspect memory counts and the estimated or measured context footprint. Existing Claude Code memory directories can be imported later with `memgit sync`.

## Tools and capabilities

- Search memories using BM25 relevance ranking and top-k results.
- Save project-scoped or explicitly global memories.
- Resume work with recent checkpoints, active work, critical memories, and depth hints.
- Inspect history with commits, logs, and diffs.
- Roll back incorrect memory state and recover older content.
- Push a store to a Git remote and share it with teammates.
- Squash history to control store growth, including stores spanning 10,000 or more sessions.
- Export and import memory data using TOON and Git-compatible workflows.
- Review token and context usage with `memgit stats`.

## Limitations and notes

Project isolation is the default. To search across projects, use `--all-projects` or the equivalent `all_projects: true`; to target one project, use `--project`. Memories without a project are global only when explicitly saved that way. If the project cannot be determined during a save, the memory is placed under `_unknown` until relabeled with `memgit doctor --relabel`.

Claude Code hooks are optional and can be disabled selectively with flags such as `--no-recall`, `--no-gate`, `--no-ctx-recall`, or `--no-guard`. The repository also describes context-footprint figures as measured where possible and estimates where labeled, so token savings depend on the contents of a particular store.

_Full upstream README: https://allmcps.com/mcp/memgit/readme_