This topic gets a memory store running and then keeps it running.
The tutorials are one path, in order. Each ends with a store that does more than the one before it, and every command shown is a command you can run.
- Install memhtml and initialize a store:
npm i -g memhtml, thenmemhtml init. One package carries the whole system and installs two binaries; the page also covers building from a clone, which is what contributors do. - Write your first memory:
memhtml write, the file it commits into the git tree, and why one fact goes in one file. - Retrieve it:
memhtml searchandmemhtml recall, and what separates them. - Wire up the MCP server:
memhtml serve mcp, and the tools and resources a client sees.
The operations pages are task-shaped how-tos, one per section of the runbook. They assume a store already exists, and each answers a question you arrived with.
| Page | Answers |
|---|---|
| Configure the environment | Which variables the binary reads, and what each one degrades when it is absent |
| Initialize a store | Why a fresh clone runs memhtml init before its first merge |
| Wire up your coding agent | What integrations install writes per host, and how uninstall removes exactly that |
| Hooks and recall | What each hook injects, why a failing hook prints nothing, and how to run one by hand |
| Run the store day to day | The daily verbs, the cron lines, and what moves the access plane |
| Share one store between a CLI and a server | Whether a command and a running server can touch one database at once |
| Rebuild the index | When update is not enough, and how to clear a vector-space mismatch |
| Preserve the state plane | The one set of facts the git tree cannot reproduce |
| Run and review a sleep cycle | Seventeen phases on a branch, how to read them, when the merge refuses |
| Check the discrimination gate | The gated number that says whether retrieval still tells a fact from its own negation |
| Audit and publish the corpus | Every memhtml doctor finding and its fix |
| Index session transcripts | The trace plane, and the firewall between it and memory retrieval |
| Diagnose poor retrieval | Where to look when nothing errors and the answers are wrong |
| Recover from a lost index | What a clone plus a rebuild restores, and what it cannot |
Before you start
Section titled “Before you start”Every command writes exactly one JSON envelope to stdout and nothing else, and sends its logs to stderr. Exit 0 is success, 2 is a usage error you fix by changing the call, and 1 is a runtime failure you fix by changing the repository or the environment (apps/cli/src/envelope.ts:87). So every command on this site is safe to pipe into jq and safe to run from cron, and the examples show the envelope rather than describing it.
The git tree is the system of record, and .memhtml/index.db is a projection of it: delete the index and you lose time rather than memories. That property is why the operations pages read the way they do. Most recovery is a rebuild, and most of what looks like corruption is a stale watermark. Store layout and path algebra develops it.
If you are an AI agent rather than a person reading a page, start with memhtml manifest. It answers with every command, flag, response type, error code, and environment variable this binary accepts, and it answers on a machine with no repository, no database, and no credentials. Come back here for the worked paths.