# How to Add Persistent Memory to Claude Code (and Share It Across Cursor, Codex, and More)

Claude Code's native memory stores text locally in CLAUDE.md and auto-memory files, but it doesn't reason a model of you and doesn't travel across tools or machines. Honcho adds one reasoned memory layer via `/plugin marketplace add plastic-labs/claude-honcho`--shared across Claude Code, Cursor, Codex, and more through a single peer.

Date: 2026-07-08
URL: https://honcho.dev/blog/blog/add-persistent-memory-to-claude-code
Tags: honcho

---

Claude Code no longer forgets everything between sessions. Since v2.1.59 (Feb 2026) it ships CLAUDE.md files and auto-memory, on by default, plus --resume transcripts. But everything it keeps is plain text, stored on one machine, keyed to one repo, readable by exactly one tool. Open Cursor or Codex and you start over. The memory that matters most (a reasoned model of how you work) isn’t there, because native memory never builds one.
This is a tutorial. In about a minute you’ll add a memory layer that reasons about you and travels across your whole stack.

Claude Code’s native memory (CLAUDE.md + auto-memory, v2.1.59) stores plain text machine-locally per repo. Anthropic’s own docs say auto-memory files “are not shared across machines or cloud environments”; it doesn’t reason a model of you.
Honcho adds a reasoned memory layer in about a minute: /plugin marketplace add plastic-labs/claude-honcho, then /plugin install honcho@honcho, then restart.
The payoff: point Claude Code, Codex, Cursor, OpenClaw, and Hermes at the same workspace and peer name and you get ONE memory--a preference learned in one agent is usable in all.
session.context() returns curated reasoning plus history in ~200ms, so you stop re-sending full history every turn--ingestion is $2/M tokens and memory benchmarks show 60-90% token savings.
Honcho reasons about the user (explicit, deductive, inductive, abductive conclusions), it doesn’t just store notes-to-self.

What does Claude Code give you natively for memory--and why isn’t it enough?
Let’s be precise, because a lot of writing on this is stale. Claude Code is not stateless-with-nothing. Since v2.1.59 (Feb 2026) it ships CLAUDE.md files, auto-memory (on by default), and --resume/--continue transcripts. Auto-memory in particular writes notes Claude decides are useful with zero human editing. If you’ve read that native memory is “just static files a human maintains,” that’s out of date.
The wedge is narrower and still true: every native mechanism is text storage, not a reasoned model of you.
Anthropic’s own framing is verbatim-defensible. The memory docs open with “Each Claude Code session begins with a fresh context window,” and describe both CLAUDE.md and auto-memory as loaded into context “at the start of every conversation… treated as context, not enforced configuration.” Auto-memory writes “learnings and patterns” as flat markdown, keyed per git repo, with only the first 200 lines / 25KB of MEMORY.md loaded. It’s notes-to-self, re-read as strings.
Three concrete limits follow:

It stores, it doesn’t reason. No layer infers your goals, models your preferences across domains, or produces queryable conclusions about you. It re-reads notes verbatim; it can’t answer a question it didn’t already write down.
It’s machine-local and per-repo. Anthropic’s docs state auto-memory files are not shared across machines or cloud environments, and the desktop app, Claude Code on the web, and VS Code extension each maintain their own session history. Knowledge about you fragments into one folder per repository; there’s no entity called “the user” that deepens across projects.
It’s locked to one tool. Nothing you accumulate in Claude Code is readable by Codex, Cursor, OpenClaw, Hermes, or Pi. A user model that lives in one CLI’s dotfiles can’t be the substrate other agents reason from.

There’s a deeper argument here about retrieval versus reasoning (why storing facts hits a ceiling on anything you never explicitly stated) but that’s the reasoning-vs-retrieve wedge, and this post assumes it.
Claude Code’s native memory stores text locally; it does not reason a model of you and does not travel across tools or machines.
How do you add Honcho persistent memory to Claude Code (step-by-step)?
One golden path, about a minute, all copy-pasteable. For session strategies, reasoning depth, and every config flag, see the Claude Code integration guide; this covers the fastest path end-to-end.
Step 1: Get an API key. Go to app.honcho.dev and copy your key (it starts with hch-). You should see the key on your dashboard.
Step 2: Add the marketplace. Inside Claude Code, run:
/plugin marketplace add plastic-labs/claude-honcho

This registers the Honcho plugin marketplace. You should see it listed.
Step 3: Install the plugin.
/plugin install honcho@honcho

This installs the memory hooks and MCP tools. You should see an install confirmation.
Step 4: Restart Claude Code.
claude

On startup you should see the Honcho pixel art and “memory loading.” Context now loads automatically at the start of every session.
Step 5: Verify. Ask:
What do you know about me?

On turn one it knows little; that’s expected, because the deriver runs in the background after messages persist. Have a couple of real turns, share something about how you work, then ask again. After a few exchanges Honcho’s reasoning builds a representation and Claude starts referencing your preferences without being re-told.
Optional: /honcho:interview conducts a short interview to capture stable, cross-project preferences (communication style, technical depth, code-quality focus) and saves each as a conclusion. All config lives in a single file, ~/.honcho/config.json, shared with every other Honcho integration, which is what makes the next section work.
Install Honcho memory in Claude Code with /plugin marketplace add plastic-labs/claude-honcho, /plugin install honcho@honcho, then restart.
How do you keep one memory shared across Claude Code, Cursor, Codex, and more?
This is the payoff that actually matters. Persistence inside one tool is table stakes. The real win is ONE memory across your whole stack: a preference learned in Claude Code is usable in Codex, Cursor, OpenClaw, and Hermes.
The mechanism is a single rule from Honcho’s design patterns: “Give each real-world entity one stable peer ID and reuse it everywhere.” Split one person across user-cursor, user-claude, and user-codex and Honcho dutifully builds three separate representations. Use one peer name and every tool reads and writes the same reasoned model.
Concretely: set the same peerName (say, alice) in each host block of ~/.honcho/config.json. Claude Code, Codex, Cursor, and OpenCode all read this shared file. If you want the tools to fully share a workspace, set globalOverride: true with a flat workspace, so each host carries only its aiPeer. Or use linkedHosts to grant one host read access to another’s context. The unified memory setup walks through it.
{
  "apiKey": "hch-v2-...",
  "peerName": "alice",
  "globalOverride": true,
  "workspace": "shared",
  "hosts": {
    "claude_code": { "aiPeer": "claude" },
    "cursor":      { "aiPeer": "cursor" },
    "codex":       { "aiPeer": "codex" }
  }
}
Beyond coding agents, the same peer’s memory reaches any MCP client through the hosted server at mcp.honcho.dev (Claude Desktop, Cline, Windsurf, Goose). Honcho is model-agnostic (OpenAI, Anthropic, custom), so a ChatGPT-style desktop client draws on the same representation your coding agents built.
Here’s the worked example. Alice tells Cursor she prefers concise TypeScript with no comments. Once the deriver has processed a few turns, that reasoning is available everywhere she shares a peer. Later, in Claude Code:
alice.chat("How does Alice like her code written?")
# -> "Concise TypeScript, minimal comments."
The answer surfaces because both tools share her peer. No re-explaining, no per-tool onboarding, no first-day amnesia when she switches editors.
Point Claude Code, Codex, Cursor, OpenClaw, and Hermes at the same Honcho workspace and peer name and a preference learned in one agent is usable in all of them.
Why is Honcho more token-efficient than re-sending conversation history every turn?
Token efficiency is the second proof, and it’s structural, not incidental. The naive approach pays for context every turn: stuff the full transcript into the window, re-send it on the next message, pay again. Honcho inverts that; pay once to reason at ingestion, then serve curated context cheaply forever after.
session.context() returns instantly-curated reasoning plus recent history in ~200ms, fast enough to call on every turn, with a token budget you set. You stop shipping the whole conversation into the context window.
The numbers back it. Ingestion (store plus reasoning) is $2/M tokens, 2.5-25x cheaper than other memory solutions. context() is unlimited and not charged separately: it’s reasoning you’ve already paid for, so we don’t hold it hostage. On memory benchmarks that translates to 60-90% token savings; Honcho’s evals show 52% fewer tokens on LoCoMo and 89% fewer on LongMemEval, answering correctly using only 11.4% of the full context.
This matters most inside a coding agent. Anthropic’s own best-practices guidance is blunt: the context window is the scarcest resource, and performance degrades as it fills, with Claude starting to forget instructions and make mistakes. Serving lean, curated context from Honcho instead of a bloated raw transcript keeps the window working for you rather than against you.
For the harder questions (how has this user’s approach to testing evolved?) peer.chat() runs on-demand reasoning at selectable depth ($0.001-$0.50 per query), so you pay for the intelligence you actually need instead of a flat rate on everything. Methodology and reproducible data are in the benchmarking write-up.
Honcho reasons over messages once at ingestion ($2/M tokens) and serves curated context via session.context() in ~200ms, cutting input tokens 60-90% versus re-sending full history.

Native memory in Claude Code answers “what did I write down in this repo, on this machine, in this tool?” That’s a filing cabinet with your name on one drawer. The interesting question is the one it can’t answer: what does this developer actually want, across every project and every agent they touch? Give that model one stable peer, share it across your stack, and every tool you open already knows you. How much of your working style are you re-explaining to each new agent, one fresh context window at a time?