How to Give Claude Code Long-Term Memory

Claude Code starts each session without the last one. The decisions you settled yesterday, the command that took an hour to find, the rule you already corrected twice: none of that is there unless you paste it back into CLAUDE.md or repeat it in the prompt. CLAUDE.md is a file on one machine. It does not record which fact mattered, and a second project has no way to keep its own copy of the same rules.

Lore is a memory server the agent reads and writes through tools. You install it once. After that, a new Claude Code session receives a startup baseline, each prompt can surface a few related memories, and Claude can save a fact that the next session will be able to find.

This guide uses Loremem Cloud, the hosted server at https://app.loremem.com. The same installer can deploy a server with Docker on your own machine. That path is in Install with Docker.

Install Lore for Claude CodeCopy Anchor Link

You need Node.js 20 or later, and the claude command on your PATH. Sign in at https://app.loremem.com/login with GitHub or Google. The first sign-in creates a personal organization and a default project. Open that project, go to the Install page, enter a token note such as laptop, and select Create token. Copy the command before you close the dialog. The token is shown once.

On the machine where you use Claude Code, run the command the page gives you, with the Claude Code channel selected:

npx @loremem/cli install --base-url https://api.loremem.com --api-token lm_your_token --channels claudecode

--channels claudecode installs only Claude Code. Without --channels, the installer connects every runtime it finds on the machine. If claude is not on your PATH, that channel is reported as skipped.

The installer registers a local plugin marketplace from ~/.lore/claudecode/ and installs the lore@lore plugin. It writes connection values into the env block of ~/.claude/settings.json: LORE_BASE_URL, LORE_HOME, LORE_CLIENT_TYPE (set to claudecode), LORE_SKILLS_ENABLED, and LORE_API_TOKEN when you passed a token. The same server and token are saved in ~/.lore/config.json, which the hooks read first. Restart Claude Code. Hooks and MCP settings load when the process starts, so an already open session keeps the old configuration.

Check the install:

1. npx @loremem/cli status should show installed on the claudecode line.
2. claude plugin list should include lore@lore.
3. In a new session, ask Claude to call lore_status. A healthy server answers that the backend is online.

Claude Code lists Lore's tools with the prefix mcp__plugin_lore_lore__, so the search tool appears as mcp__plugin_lore_lore__lore_search. You can still refer to it as lore_search when you talk to Claude. The parameter names are the same in every runtime.

--api-token leaves the token in your shell history. Keep the token in a password manager, and do not paste it into shared logs. Tokens look like lm_your_token. You can revoke one later on the Tokens page.

Claude Code also has its own auto-memory. If you want Lore to be the only memory, set autoMemoryEnabled to false in ~/.claude/settings.json, or set CLAUDE_CODE_DISABLE_AUTO_MEMORY to 1 in that file's env block. Lore does not write to CLAUDE.md.

What a new session already knowsCopy Anchor Link

Start a new session and ask Claude what it loaded at startup. The answer should come from the boot nodes, not from the current folder.

Lore injects four fixed nodes at session start:

You edit these in the console. On a fresh server the setup step offers default text, and you can change it later. Boot nodes are not returned by recall, because the session already has them. The boot block also lists the five most recently written memories by path, priority, and disclosure, without their content.

A generic MCP client does not get this injection. It has to call lore_boot itself. Claude Code's SessionStart hook does that for you. Each hook waits at most 10 seconds. If the server is down, the hook returns nothing and Claude continues without memory for that step.

What Claude sees on a promptCopy Anchor Link

Send a prompt that uses the words of a memory you have already saved. Claude's context gets a block like this:

<recall session_id="sess_8f3c" query_id="q_41" phase="prompt">
0.82 | project://checkout_api/webhooks
0.71 | project://checkout_api/testing
</recall>

Each line is a score and a URI. Candidates below the display threshold are left out, and the block keeps only the few that scored highest. If nothing clears the threshold, no block is added. That is normal for a new project. On a self-hosted server the same line also prints the terms that matched the prompt, after the URI.

A line is a lead, not the fact. Before relying on it, Claude opens the node with lore_get_node and passes the session_id and query_id from the tag:

{
  "uri": "project://checkout_api/webhooks",
  "session_id": "sess_8f3c",
  "query_id": "q_41"
}

Those two identifiers are how Lore records that a recalled memory was actually used. Opening the node without them still returns the content, and the recall analytics will not count it as used.

A slow search is skipped rather than holding the prompt. On Loremem Cloud, open Overview to confirm the request arrived. The Queries count rises after each prompt. A self-hosted server shows the same count under Analytics.

Ask Claude to save the next factCopy Anchor Link

A new graph has little to recall, so write one fact you will reuse. Say where it belongs, and ask Claude to look for an existing node first:

Save this as a long-term memory for the checkout_api project. Search first, and update the node if one already owns this topic. Create the parent project://checkout_api first if it does not exist. Then create project://checkout_api/webhooks with priority 1, a disclosure for changing refund or payment webhooks, and the glossary terms refund webhook, idempotency key, and stripe. Content: refund webhooks are idempotent by event.id, and tests must replay the same event twice and assert a single refund row.

The saved node has this shape:

URI:        project://checkout_api/webhooks
Priority:   1
Disclosure: When changing refund or payment webhooks in checkout-api
Glossary:   refund webhook, idempotency key, stripe
Content:    Refund webhooks are idempotent by event.id. Tests must replay the same event twice and assert a single refund row.

The path names the concept. Keep it lowercase snake_case, and keep dates out of it. A child path needs its parent first, and the parent needs its own content, disclosure, and glossary. Priority 1 is for a key fact. Lore allows at most 15 nodes at priority 1, and at most 5 at priority 0. Priority 2 and above is for everything else. Disclosure names one future situation, not a summary of the content. Glossary is the words you actually type, including the other language and the error name.

Claude writes this with lore_create_node. If a node already owns the topic, lore_update_node changes only the fields you send. The omitted fields stay as they are. Do not put API keys, tokens (including lm_ tokens), passwords, or connection strings into a memory. History and backups keep earlier versions, so deleting the text later does not remove the secret.

Then check recall. Send "How should I test refund webhooks in checkout_api?" and ask Claude to quote the <recall> block it received. If the new memory is one of the lines, the next session can find it without you pasting anything.

The field rules, and a longer checklist for what belongs in memory, are in Writing good memories. The install details specific to this runtime are in Claude Code.