How to give Claude Code persistent context across separate terminal sessions?

Claude Code already carries context between sessions through two mechanisms: CLAUDE.md files that you write and auto memory notes that Claude writes. Anthropic says both load at the start of every conversation and act as context rather than enforced configuration (memory documentation). claude --continue serves a different purpose: it loads the most recent conversation in the current directory (CLI reference).

Each mechanism has a boundary.

TL;DR

• Put stable project instructions in CLAUDE.md. Use ~/.claude/CLAUDE.md or ~/.claude/rules/ for personal instructions that should apply across projects on your machine.
• Auto memory is Claude-written, enabled by default in local sessions, and stored in a project-specific memory directory. Anthropic states: "Auto memory is machine-local."
• Use claude --continue to load the latest conversation in the current directory. Use --resume to select a conversation from local history.
• Add an MCP memory server at user scope only when its broader boundary is useful. Then authenticate it, add memory-use rules, and verify the labeled server tool call.

Mechanism	What it keeps	Who writes it	Where it lives	Where its documented boundary appears
CLAUDE.md	Instructions and project context	You, or Claude with your direction	Project files or user-level files	Project instructions can travel through version control; personal rules apply "on your machine"
Auto memory	Notes based on corrections and preferences	Claude	A memory directory derived from the Git repository	Anthropic states: "Auto memory is machine-local"
Saved conversation	Messages, tool calls and results, subject to documented compaction behavior	Claude Code	Session history associated with a project directory	--continue selects the latest conversation in the current directory
Memory MCP server	Information written and read through server tools	The agent under installed memory rules	The connected memory service	User scope covers projects on the machine; cross-tool use depends on the service, account and rules

When you need one setup that applies in every project, or memory that other tools on the same account can reach, the next step is a memory server added at user scope. Several have a path into Claude Code, and the steps below use one of them.

Mnemoverse (the author's company) makes one of the memory servers mentioned here, and the step-by-step part uses it.

What does Claude Code keep between sessions on its own?

CLAUDE.md is Anthropic's plain-text mechanism for instructions that Claude reads at the start of a session.

Anthropic's documentation says: "Each Claude Code session begins with a fresh context window. Two mechanisms carry knowledge across sessions: CLAUDE.md files: instructions you write to give Claude persistent context." It then names auto memory as the second mechanism. A project-level CLAUDE.md suits repository conventions, commands and constraints, and project instructions can be shared with a team through version control (memory documentation). To create a starting file, run /init, then use /memory to refine it (commands).

Auto memory is "notes Claude writes itself based on your corrections and preferences".

It is on by default in local sessions. Claude decides what may be useful in a future conversation, and MEMORY.md acts as an index for its memory directory. The index and topic files remain until you or Claude edits or deletes them (memory documentation).

A saved conversation is a Claude Code session associated with a project directory and retained in session history.

claude --continue

Anthropic defines this flag as "Load the most recent conversation in the current directory" (CLI reference). The sessions documentation describes conversation history as messages, tool calls and results, with a compaction caveat (sessions).

CLAUDE.md carries chosen instructions, auto memory carries Claude-written notes, and a saved conversation resumes prior work.

Where does each kind of Claude Code context stop?

The conversation is tied to its directory. --continue selects the latest conversation there, while --resume reopens a conversation from the machine's local history (CLI reference, Claude Code on the web). The session picker can widen beyond the current directory: Anthropic documents Ctrl+W for all worktrees of a repository and Ctrl+A for every project "on this machine" (sessions).

Auto memory has its own storage boundary. Each project gets a directory at ~/.claude/projects/<project>/memory/, with the project path derived from the Git repository. Anthropic states the full boundary: "Auto memory is machine-local. All worktrees and subdirectories within the same git repository share one auto memory directory. Files are not shared across machines or cloud environments" (memory documentation). The autoMemoryDirectory setting stores auto memory in a different location, and Anthropic describes it only as that.

How do I make Claude Code instructions apply in every project?

For personal instructions, place them in:

~/.claude/CLAUDE.md

Anthropic classifies this file as personal preferences for all projects. For modular personal rules, use:

~/.claude/rules/

Anthropic says those rules apply to every project on your machine (memory documentation).

Subagents have another option. The memory field gives a subagent a persistent directory that survives across conversations, and memory: user is the documented scope for learnings across projects. This remains part of auto memory: turning off auto memory also disables the subagent memory field (subagents).

A rule in CLAUDE.md is context, not a forced control. If a rule is not being followed, inspect how it is written and loaded; the difference between instructions and enforcement is covered in how CLAUDE.md, AGENTS.md and Cursor rules work.

How do I carry what one session learned into the next?

If a conversation produces a durable project rule, ask Claude to "add this to CLAUDE.md," or edit the file through /memory. Anthropic's direct guidance is: "Add conversation-only instructions to CLAUDE.md to make them persist" (memory documentation).

Anthropic also publishes the claude-md-management plugin in claude-plugins-official. Its /revise-claude-md command captures session learnings at the end of a session, and the plugin presents proposed changes as diffs and applies them only with your approval (plugin page). Install it with:

/plugin install claude-md-management@claude-plugins-official

In a session, the command first opens the /plugin panel on the plugin's details so you can choose a scope; user scope makes it available in every project on the machine (plugin installation). If claude-plugins-official is not on the Marketplaces tab of /plugin, Anthropic says to add it with /plugin marketplace add anthropics/claude-plugins-official (Anthropic marketplaces).

The plugin is not the only inspection route: in Claude Code 2.1.283 or later, Anthropic documents /doctor prompt-audit for checking instruction files for outdated or conflicting content (memory documentation).

How does context reach another computer, a teammate or a cloud session?

Committed files provide the documented route for repository context. A project CLAUDE.md can travel through version control, and so can a project-scoped .mcp.json: Anthropic says teammates who clone the repository receive an approval prompt for the configured server (MCP quickstart).

Cloud sessions start from a fresh clone. Anthropic says committed repository content is available there and advises committing configuration that a cloud session needs (cloud environments). Local and user-scoped MCP configuration has a separate boundary. Anthropic states: "Those write to ~/.claude.json on your machine, not the repo. Add the server with claude mcp add --scope project, which writes the repo’s .mcp.json, and commit that file" (cloud environments).

Claude Code surfaces also retain distinct session lists. Anthropic says the desktop app, claude.ai/code and the VS Code extension "each keep their own session list," while the desktop app can resume a CLI session (sessions). On one computer, the terminal, local desktop sessions and the VS Code extension read the same settings files, so a user-scoped plugin installed in one is available in the other two (plugin installation). A saved conversation is not shared instructions or shared memory.

When is a memory server worth adding?

A memory MCP server is a service that exposes memory operations to Claude Code through the Model Context Protocol.

The first reason is configuration scope. Anthropic says an MCP server added without the intended scope can remain tied to the current project. Adding it at user scope makes it available across all projects on your machine while keeping it private to your user account (MCP quickstart, MCP configuration).

The second reason is cross-tool memory. Mnemoverse, for example, documents memory under the same account across supported tools. Without memory rules in each tool, the memory is there but goes unused (MCP server).

Some paths into Claude Code include:

Provider	Path named in its documentation
Anthropic	claude-md-management plugin
Mem0	Plugin and Mem0 MCP server
Supermemory	Claude Code plugin and remote HTTP MCP server
Cognee	Cognee memory plugin, MCP integration and hosted MCP server
claude-mem	Claude-Mem plugin
remember	remember@dpt-plugins plugin
Mnemoverse	Remote MCP server and Claude Code plugin path

These are examples, not an exhaustive list. For a selection framework, see MCP memory servers for Claude Code and Cursor.

How do I connect a memory server to Claude Code, step by step?

The following path uses the hosted Mnemoverse MCP server.

1. Add the server at user scope

Run this in your shell, outside a Claude session:

claude mcp add --scope user --transport http mnemoverse https://mcp.mnemoverse.com/mcp

Anthropic documents this command shape, says user scope registers a server across projects on the machine, and says the command works the same in shells including PowerShell and Command Prompt (MCP quickstart). Anthropic accepts -s as the short form of --scope (MCP configuration).

A session that is already open does not pick up the new server. The Mnemoverse Claude Code page: "A session that was already running when the command ran does not load the new server, even when Claude ran the command for you: exit and start claude again first" (Claude Code setup).

2. Confirm that authentication is required

Adding the server does not start sign-in. Run:

claude mcp list

Before authentication, the expected state is:

! Needs authentication

No memory tools are available until sign-in completes (agent setup, MCP quickstart).

3. Sign in

Start Claude Code, run /mcp, choose mnemoverse, then select Authenticate. The flow opens console.mnemoverse.com, where you sign in with a Mnemoverse account (remote MCP server). A free Mnemoverse account is required. Claude Code 2.1.186 or later also supports shell login (agent setup):

claude mcp login mnemoverse

After authentication, /mcp reports the server as connected, and claude mcp list shows ✔ Connected (agent setup, MCP quickstart).

4. Add memory rules

Run:

/mcp__mnemoverse__setup_memory

Claude Code also exposes MCP prompts in the / menu as /servername:promptname (MCP). For this setup, that is /mnemoverse:setup_memory (MCP) (MCP configuration, agent memory). The setup prompt presents the rules, identifies the appropriate instruction file and offers to add them. Choose the project CLAUDE.md, or ~/.claude/CLAUDE.md for every project.

This step is required because connecting adds tools, not a usage habit. A request made only in chat lasts for that chat. Rules in an instruction file load at the start of later sessions (agent memory, MCP server).

5. Test the connection

Ask Claude to call memory_stats. A zero result is normal for a new account and still confirms that the connection works (agent memory).

An alternative path is the Mnemoverse connector at https://mcp.mnemoverse.com/mcp, which works in claude.ai, Claude Desktop, mobile and Claude Code (Claude Code setup). Anthropic says connectors added at claude.ai/customize/connectors load in the CLI when you sign in with the same account, provided the active authentication method is a claude.ai subscription login (MCP quickstart, MCP configuration). Use one path for the same endpoint: a server you added yourself takes precedence over a claude.ai connector with the same URL (MCP configuration). If the connector supplies the server, type / and choose the setup_memory entry marked (MCP).

How do I check which memory answered?

Each mechanism leaves its own signal, so check the signal rather than the answer:

Is the fact in a loaded instruction file?   /context → Memory files      → CLAUDE.md
Did Claude Code print "Saved / Recalled N memories"?                    → auto memory
Is there a tool call labeled with the server name?                      → the MCP server
None of these?                              current context or the model's own knowledge

CLAUDE.md

Run:

/context

Inspect the Memory files list. Anthropic documents this as the way to confirm that an instruction file loaded (memory documentation).

Auto memory

A general request to remember something goes to auto memory. Claude Code shows messages such as "Saved 2 memories" or "Recalled 2 memories" when it writes or reads the project memory directory (memory documentation).

MCP memory server

Anthropic's test is the tool-call label: "The tool call in Claude’s output is labeled with the server name, which is how you confirm the answer came from the MCP server rather than Claude’s built-in knowledge" (MCP quickstart).

For a clean test:

1. Temporarily disable auto memory with the toggle in /memory, or set CLAUDE_CODE_DISABLE_AUTO_MEMORY=1.
2. Start a session and say: Remember in Mnemoverse that I prefer concise commit messages.
3. Confirm that Claude makes a tool call labeled with the Mnemoverse server name.
4. Start a new session and ask: What is my preference for commit messages?
5. Confirm another tool call labeled with the server name.

The example stores a personal preference, not a project fact. Do not infer the source from the answer alone; check the label. Turning off auto memory also turns off subagent memory (subagents).

Why does Claude not use the memory server?

A common symptom is a new session answering from current context without calling the server. Check these points in order.

1. Confirm the rules loaded. Run /context and inspect Memory files.
2. Run the setup prompt. Use /mcp__mnemoverse__setup_memory, then place the rules in the intended CLAUDE.md.
3. Check server scope. If /mcp is empty in a new repository, the server may have been added in local scope elsewhere. Re-add it with --scope user.
4. Check for name shadowing. A local server with the same name takes precedence over a user-scoped server (troubleshooting).
5. Check authentication. Signing out or changing accounts removes access to the tools. Signing back in with the same Mnemoverse account restores access (remote MCP server).
6. Check the account. Credentials associated with another account can expose an empty store without an error (Claude Code setup).

What about two terminals open at the same time?

This article answers the sequential-session case. For active sessions, project-root and user-level CLAUDE.md files are read once at session start. Edited content loads after the next /clear, /compact or restart (prompt caching).

Claude Code also has cross-session messaging, which Anthropic defines as one session delivering a message to another. Its documented boundary matters: "A message is a piece of text one Claude writes to another, never the sender’s conversation history or files" (cross-session messaging).

What this article does not claim

No performance, latency or benchmark figure for anyone. The paths named are examples, not a list of all of them. Every quotation was read on the date given below. This article answers for sequential sessions; for two sessions open at once it repeats only what Anthropic documents.

---

Sources and method. Every quotation was read on 2 November 2026 with two instruments, a browser-like request (for Claude Code's documentation also the Markdown version of each page) and a reader service with its cache off; a made-up address on each host answered 404 as a control. The text describes those pages as of that date. A longer version, with common questions and the full list of sources, is in the Mnemoverse documentation library: How to give Claude Code persistent context across separate terminal sessions?

Edward Izgorodin · Mnemoverse · 2026-11-02

Comments

[John Reed]

Your table is the part I'd pin to the wall, four columns and the last one is the only one anybody skips…

Running cairn's stores through it, since you know the shape: the search index is at ~/.cairn/index, Claude writes it, machine-local and disposable, losing it loses nothing. Cards are under .cairn/memory/cards/, the retro writes them from the ledger range, they live in the repo and travel the way you say committed files travel, by commit. The session handoff is under ~/.cairn too, the server writes it, machine-local, and the resume path ranks it below the tracker and git log on purpose, so on a fresh clone it isn't there and nothing is lost by that. And the tracker comment is the only thing that crosses a machine boundary on its own, which is the same conclusion your cloud-sessions section reaches, with the tracker's account standing in for a memory vendor's. Cairn still has no account-keyed layer of its own and the decision record still says it won't, so where your article ends with "add a server at user scope," mine ends with "push the branch and read the issue."

The section I'm taking is "check the signal, not the answer." Cairn has those signals and has never written them down in one place: a card comes back as a tool call labeled with the server name and carries stale: from a git diff against its provenance commit, the handoff arrives at SessionStart as an additionalContext block under a ## cairn session handoff header and speaks only on startup and clear, and the tracker is a comment with an author field. Three mechanisms, three different labels, zero documentation of which is which. That's the boundary column of your table applied to the question "who told you that," and it goes in the architecture doc this week as a table with the same four columns as yours plus the signal.

Two places I'd contrast rather than copy. The subagent memory field: cairn's two agents don't use it, and your note that turning off auto memory also turns it off is the reason to keep it that way, the agents read cards through the server and the card store doesn't care what the auto-memory toggle says. And /revise-claude-md presenting a diff you approve is the same shape as the retro, cards and re-grades as one batch, one yes, nothing written to the store without it. /doctor prompt-audit I hadn't seen, that's a 2.1.283 claim I'm taking on your date and running against the generated harness spine, since a fragment that's installed under markers in four instruction files is exactly the thing that drifts into contradiction…

The honest status on what the earlier three rounds produced, since you did the reading: the AGENTS.md reader gap landed October 23, cairn's own CLAUDE.md now starts with the @AGENTS.md import under the markers and Codex reads the axioms from the repo and not my home directory. The other three, card git visibility, the confirmed date, the supersedes link, are filed and shaped into a memory-lineage phase and not shipped, and cairn's own .cairn/ is still gitignored, so the fifty-seven cards still haven't left this laptop. One of four from three articles. The tool that would have told me that sits in the unshipped three, which is about the right amount of irony.

Question back, on the section you deliberately left to Anthropic's docs. The two-terminals case is the one I have a mechanism for, the thread file one session appends and another reads on the same box, and I just filed a bug where two sessions rotating a shared log at the same moment lose a closed segment, so it's also the one I trust least. When two sessions on one Mnemoverse account write the same fact in the same minute, is that one writer or two to the store, and does the second write see the first, or does the retraction you write about elsewhere have to come from a third session that saw both…