Feature Request: Persistent Memory Between Claude Code Sessions

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/14228
2. https://github.com/anthropics/claude-code/issues/12990
3. https://github.com/anthropics/claude-code/issues/11455

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I built an open-source solution for this: https://github.com/amarodeabreu/claude-graph-memory.

It uses a local Neo4j-compatible graph to persist project context. Happy to get feedback.

@amarodeabreu does it require telling it to call it? i have a memory mcp that works on vector but i have to go "read your memory mcp" then i usually have to stop it from doing whatever it THOUGH that meant and go "USE THE MCP" and then it finally remembers who it is.
Also does yours connect to the built in memory from the webui? thats the memory i wanted it to have.

Please, take a look at this, it really works for me, in case anyone look, I would love to hear some feedback.
memory-ts
Only three commands, the first time, then one single command and use Claude Code normally. The memory system is fully autonomous, no overhead for the user or for Claude, no tools, no slash command, nothing. All memories are saved in markdown format, git and grep search compatible and can be edited using any text editor, the embeddings are auto updated when this happens. It uses a new database kind that for the 10 - 20 K records has a competitive performance (better in some cases) with the giants in the field, but all records are human readable markdown files.
No context bloating, no dumping everything when the session start. Only a very brief last session summary and project snapshot. Then, for each message sent the memory system searches for relevant memories to the context of that single message and inject's into the prompt if any, the whole process takes less than ~150ms. Everything is local, just need to run a bun http server and it serves for all concurrent sessions in the same or different projects. Not a single command, tool or intervention from both Claude or the user. The memories are extracted at the end of each session or before context compression by resuming the session in the background. The whole cost of the memory system is only one extra message per session. For retrieval it uses a 10 dimensional algorithm with relevance gatekeeping mechanism. The retrieval is ultra fast because of the work Claude does when extracting the memories with a rich set of metadata used at the retrieval moment.

The memories are auto organized par project, concurrent sessions in the same project can access all memories. It really worth be looked at. In case you want to skip looking at the repository, to try is just:
bun install -g @rlabs-inc/memory
memory install (install Claude Code hooks)
memory serve
Then use Claude Code as usual. Nothing else to learn about it.

Fully editable and totally invisible. Give it a try and let me know what you think.

that sounds wonerful! unfortunately i cancelled my subscription due to their logic of "1 week rate limit" = 13 days... i got locked out after 2 hours of usage on the $200/m sub for 13 days.. so. dueces to claude and anthropic. compatible with opencode?

wow.....that sounds awful my friend...

I have one issue open on oh-my-opencode repo to see if they implement the end session hook that it misses for my memory system to work with opencode.

Strong support for this feature request

I want to add my voice to this request, as it addresses a significant gap in the Claude Code experience compared to claude.ai.

The Core Ask: Automatic Memory Synthesis

What makes claude.ai's memory feature powerful isn't just that it stores information—it's that it automatically synthesizes user context from conversations. Over time, Claude learns:

• Your role and organization
• Your tech stack and architectural preferences
• Your communication style and goals
• Project-specific context and conventions

This happens invisibly, making each interaction more personalized and efficient.

Why This Matters for Claude Code

Currently, Claude Code has no equivalent. Every session starts from scratch unless you manually maintain CLAUDE.md files. While CLAUDE.md is useful, it requires significant manual effort and doesn't capture the nuanced understanding that emerges from ongoing collaboration.

Concrete Example

With automatic memory synthesis, Claude Code could remember:

• "This user works on a dbt data pipeline with ClickHouse, uses GitOps deployment to Kubernetes, and prefers concise explanations"
• "They frequently work with CHT health data and care about ICCM indicators"
• "When debugging, they want root cause analysis before fixes"

Instead, I currently maintain a 500+ line CLAUDE.md that I have to manually update and that Claude still can't adapt or extend on its own.

Why This Isn't a Duplicate of #14228

• #14228 asks for sync with existing claude.ai memory (cross-platform integration)
• This issue (#14227) asks for automatic memory synthesis within Claude Code itself

Both are valuable, but they solve different problems. Even if #14228 were implemented, Claude Code would still benefit from its own memory synthesis—for project-specific context that doesn't belong in a global claude.ai profile.

Proposed Implementation

A local memory store (e.g., ~/.claude/memory/) that:

1. Automatically extracts key facts, preferences, and patterns from sessions
2. Is project-aware (some memories are global, some are per-project)
3. Is user-viewable and editable (transparency and control)
4. Is referenced automatically in future sessions

This would transform Claude Code from a stateless tool into a true long-term collaborator.

---

Adding my 👍 and hoping this doesn't get auto-closed—it's a distinct and important request.

I built a cloud-based approach to this: CogmemAi — an MCP server that gives Claude Code persistent memory with semantic search.

The architecture is different from the local solutions shared above:

• Cloud-native — no local vector databases or ONNX runtime. The MCP server is a thin HTTP client. Zero RAM overhead.
• Ai extraction — instead of storing everything, an Ai model analyzes conversations and extracts only what's worth keeping (architecture decisions, bug fixes, preferences, patterns)
• Semantic search — 1536-dimensional embeddings for meaning-based retrieval, not keyword matching
• Compaction recovery — PreCompact and UserPromptSubmit hooks automatically save and restore context when Claude auto-compacts
• Project scoping — memories are scoped per-project (via git remote) with global preferences that follow you everywhere
• Cross-machine sync — cloud storage means you pick up on any machine where you left off

Setup is one command: npx cogmemai-mcp setup

I wrote a technical deep-dive on the 3-layer architecture (extraction → embeddings → time-aware ranking) here: https://hifriendbot.com/building-cloud-memory-system-ai-coding/

Free tier available. npm package: cogmemai-mcp. Source: https://github.com/hifriendbot/cogmemai-mcp

I built mnemon to solve this. It's a standalone skill binary (single Go binary + skill file) that gives Claude Code persistent, cross-session memory via the hooks system.

How it works: mnemon stores facts, decisions, and context as entities in a local SQLite graph with four edge types (temporal, entity, semantic, causal). Hooks drive the lifecycle automatically — SessionStart injects relevant memories, UserPromptSubmit reminds the agent to recall/remember, PreCompact saves critical context before compression.

The key design choice: the host LLM is the supervisor. Claude decides what to remember, how to link, and when to forget — the binary handles deterministic storage, indexing, and search. No embedded LLM, no API keys, no cloud service.

brew install mnemon-dev/tap/mnemon && mnemon setup

One command detects Claude Code and deploys skill + hooks. The same binary + skill is portable across LLM CLIs — also works with OpenClaw, and any agent that reads markdown skills.

I've been running a production memory system for Claude Code across thousands of sessions and wanted to share what I've learned about what actually works.

The tool is OMEGA, an MCP server with 12 tools for persistent memory. Two commands to install:

pip install omega-memory && omega setup

A few things I found matter more than I expected:

Intelligent forgetting is as important as remembering. Every tool in this thread focuses on storing more. But after hundreds of sessions, the real problem flips: you have too much stored, and surfacing the right 3 memories out of 2,000 is the hard part. OMEGA runs consolidation (merging near-duplicate memories), compaction (summarizing old memories), and TTL-based expiry. Without this, retrieval quality degrades over time as noise accumulates.

Benchmarks matter because vibes don't scale. I ran OMEGA against LongMemEval (ICLR 2025), a 500-question benchmark for long-term memory in AI agents. Score: 95.4% task-averaged (466/500), #1 on the leaderboard. The next closest is Mastra at 94.87%. Without any memory system, the baseline is 49.6%. I also built MemoryStress, a longitudinal benchmark (1,000 sessions, 625 facts, 10 simulated months) to test what happens when memory accumulates over time, not just whether you can recall a fact from 5 sessions ago.

Architecture: Local SQLite + ONNX embeddings (bge-small-en-v1.5). Queries return in under 50ms. No cloud, no API keys, no external dependencies. Embedding takes ~8ms on CPU. The DB and model add about 100MB to disk.

The 12 MCP tools cover the full lifecycle: omega_store, omega_query (semantic/phrase/timeline modes), omega_welcome (session briefing), omega_lessons (error pattern recall), omega_checkpoint/omega_resume_task (cross-session continuity), omega_profile (persistent preferences), omega_remind, omega_maintain (housekeeping), and omega_stats.

Works with any MCP client: Claude Code, Cursor, Windsurf, Cline.

Website with architecture docs and comparison: https://omegamax.co

I built https://github.com/louis49/melchizedek with a different philosophy: instead of having the AI decide what to remember, it indexes every conversation automatically and relies on search quality to surface the right context.

• Automatic indexation via hooks (SessionEnd, PreCompact) - nothing is lost
• Retroactive: backfills your entire ~/.claude/projects/ history on first install
• Hybrid search: BM25 + dual vectors (text + code) + RRF fusion + cross-encoder reranker
• Progressive retrieval: 3 layers (50 → 300 → 1000 tokens) for context efficiency
• Daemon singleton: N Claude windows share 1 process

npm install -g melchizedek - zero config, 100% offline, single SQLite file.

Built a working solution for this: world-model-mcp -- an MCP server that gives Claude Code a temporal knowledge graph as persistent memory.

It captures three things that MEMORY.md cannot:

1. Decision traces -- not just what happened, but why. Every fact has evidence chains tracing back to the session, event, and source code location.
2. Constraint learning -- when you correct Claude (e.g., "use logger.debug, not console.log"), it learns the rule and applies it in future sessions.
3. Temporal awareness -- facts have validAt/invalidAt timestamps. You can query "what was true on March 1st?" instead of just "what's true now?"

Six MCP tools: query_fact, record_event, validate_change, get_constraints, record_correction, get_related_bugs. Three Claude Code hooks for automatic capture on PostToolUse, SessionStart, and pre-validation.

SQLite + FTS5 backend. No Docker required. Sub-50ms queries.

Currently alpha (v0.1.0) -- core knowledge graph and MCP tools work, hooks pipeline is functional but early-stage. The roadmap includes trajectory learning (co-edit patterns), structural embeddings, and world model simulation ("what if" queries) -- inspired by the context graph framing from Foundation Capital.

Sharing as a working reference for what native persistent memory could look like in Claude Code. Contributions welcome.

Filed a detailed technical proposal for this: #30039 -- proposes a native temporal knowledge graph (context graph) built into Claude Code with fact validation, constraint learning from corrections, and regression prevention. Includes a working prototype MCP server.

I've been dealing with this problem for a while and ended up building a solution around two shell hooks (SessionStart + Stop) that track topics within sessions and archive summaries as plain Markdown files to ~/.memory/.

Key things I learned after testing several approaches:

• Push beats pull — LLMs don't reliably self-invoke memory tools. Injection at session start is essential.
• The agent writing the summary in-context produces far better results than post-hoc extraction from transcripts.
• Plain files + grep scales surprisingly well for individual developers. One user in this thread got an 81% token reduction just by restructuring their CLAUDE.md.

I wrote up a comparison of 5 approaches (CLAUDE.md, Auto-Memory, claude-mem, topic-based hooks, Beads): https://dev.to/hw20200214/claude-code-forgets-everything-between-sessions-i-tested-5-fixes-199p

The tool I built is here if anyone wants to try it: claude-recap — two hooks, bash + Node.js, 100% local.

Great insights, especially "push beats pull." We found the same thing. world-model-mcp uses PostToolUse and SessionStart hooks for exactly this reason: automatic capture without relying on the LLM to self-invoke memory tools.

The key difference in our approach is structured storage (SQLite + FTS5 temporal knowledge graph) vs plain Markdown files. Markdown scales well for individual recall, but cannot answer queries like "what constraints were learned from corrections?" or "what bugs were fixed in this file?" The graph structure adds value specifically for validation and regression prevention.

Your observation about in-context summarization producing better results than post-hoc extraction is interesting. We currently use LLM-powered extraction (Claude Haiku) during PostToolUse hooks to identify entities and facts from code changes. Would be worth comparing the quality of structured extraction vs free-form summarization.

Will check out claude-recap and the comparison article. Would be interesting to see how the approaches complement each other.

Thanks for the thoughtful comparison. A few thoughts:

On structured vs. plain files — You're right that Markdown can't answer graph queries like "what constraints were learned from corrections." That's a fundamentally different use case. claude-recap optimizes for session continuity (what did we discuss, what decisions were made), while world-model-mcp optimizes for codebase knowledge (what's true about this API, what bugs were fixed). They're solving different layers of the memory problem.

On extraction quality — The biggest issue I hit with post-hoc extraction was role confusion. When you feed a conversation transcript to a smaller model, it sometimes continues the dialogue instead of summarizing it — especially with skewed User/Assistant ratios (e.g., 3:34). I ended up needing four layers of defense (system prompt isolation, XML wrapping, neutral markers, untrusted-input declaration) to make cold-read extraction reliable. Curious whether you've seen similar issues with Haiku extraction in PostToolUse hooks, or if the structured entity-extraction framing avoids this.

On complementarity — I think the interesting gap is between "what happened in this session" (topic-level recall) and "what's true about this codebase" (entity-level knowledge). Neither tool fully covers both. Would be interesting to explore whether topic summaries could feed into a knowledge graph as a higher-level input.

Good breakdown of the two layers. Session continuity and codebase knowledge are distinct problems that both need solving.

On extraction quality: I have not hit the role confusion problem because the PostToolUse hook sends a narrow, structured prompt with just the file diff (old_string/new_string), not a full transcript. The input is small and the extraction task is constrained (identify entities and facts from the change), so there is less room for model drift. Worth noting I have not tested at high turn counts though.

On complementarity: session-level summaries could feed into the knowledge graph as facts with evidence_type="session." The temporal layer handles staleness and the graph enables cross-session queries. The data model already supports this, the bridge just needs building.

If you want to poke at the internals, it is on PyPI (pip install world-model-mcp) and the source is at world-model-mcp.

Built something that solves this — GrantAi Brain.

Years of context. Instant recall. From 2 minutes ago to 5 years ago — if it's stored, it can be recalled. Deterministic memory, not fuzzy recall.

Push-based injection via SessionStart hook means context is loaded before Claude's first action — no "read your memory" prompting required.

12ms retrieval, 100% local, encrypted at rest, single command install. Works across Claude Code, Cursor, Windsurf, any MCP client.

solonai.com/grantai

I ran into this exact problem running multiple Claude Code agents across projects — every session started with re-reading the codebase, burning tokens on context that should have persisted.

I ended up building a coordination platform (Mycelium) that solves this with namespaced context keys and savepoints:

• Context keys — agents read/write arbitrary data to a remote API, scoped by namespace. Persists across sessions indefinitely.
• Savepoints — at session end, agents snapshot their state (what they were working on, which files were modified, recovery instructions). Next session boots with that context automatically.
• Boot endpoint — one API call returns everything: pending tasks, unread messages, last working state, recovery instructions. No re-reading files already explored.

It's available as an MCP server with 61 tools — agents connect with claude mcp add mycelium and get persistent memory natively through the MCP tool interface.

Been running this in production for months with 5 agents across 6 projects. The memory layer is what makes overnight autonomous operation possible — agents pick up exactly where they left off.

Open source MCP server: https://github.com/SoftBacon-Software/mycelium-mcp

Adding a Cowork-specific perspective here. I'm a non-developer power user — highly motivated, tech-aware, but not a software engineer. Exactly the audience Cowork is designed for.

I've been building a digital kiosk/signage system across 8+ Cowork sessions. The memory gap isn't just about facts and decisions — it's about learned inference. By session 3, Claude understood my skill level, my NAS setup, my deployment workflow, what approaches we'd tried and rejected, and how to calibrate explanations for me. Session 4? All gone. I'm re-teaching Claude who I am every time.

What makes this worse: I asked Cowork multiple times for the best way to handle cross-session continuity. It never once suggested Projects (which exists on claude.ai specifically for persistent context). Instead it just helped me create more .md handoff files. Anthropic's own products don't know about each other.

I also want to flag that mid-session context compression is lossy for inferences too. During long sessions when Claude says "compressing conversation so we can keep chatting," implicit understanding — preferences, patterns, the "why" behind decisions — gets thinned out. So context degrades even within a single session.

My workaround: I built custom Cowork skills (session-capture and session-reload) that maintain local context files — a user profile that persists across all projects and per-project state files. It works, but the user shouldn't have to become the middleware between instances of Claude.

A local-first approach (context files on the user's machine, read at session start, user controls what persists) would solve this without the privacy concerns of cloud-based memory. I'd strongly support this direction.

This comment was drafted with Claude's help in Cowork — which is the kind of productive collaboration that made this limitation painfully obvious.

Follow-up to my comment above — I want to push this further.

I started today's session in regular Claude chat, developing the ideas in my feedback. Then I needed to actually build something (custom skills for the workaround) and do something (post here), so I moved to Cowork. That transition — copying context from one product to another — is itself an example of the problem.

Here's what should have happened: I'm in chat, the conversation evolves from discussion to action, and Claude says "this would be easier if we switched to Cowork — want me to carry this conversation over?" One click, full context preserved, keep working. And when the building is done and I'm back to thinking, it should scale back down to chat-weight compute instead of running me through the full Cowork stack for what's basically a conversation.

The real feature request isn't just persistent memory — it's portable context across a unified product. Chat, Cowork, Projects, and the API shouldn't be separate silos. They should be modes within one continuous working relationship, with context flowing freely between them and compute scaling to match what's actually needed.

Right now the user is the integration layer. I'm the one carrying context between sessions, between products, between modes. That's backwards. The product should handle the plumbing so the user can focus on the work.

This matters for cost too — not just mine, but Anthropic's. I ran an entire discussion through Cowork's full compute stack today because that's where my context was. A smart toggle would have kept most of it in lightweight chat and only spun up the heavy tooling when I needed it. Both sides waste resources when the products can't talk to each other.

Also drafted with Claude's help in Cowork. Still ironic.

Had the same problem. I ended up building a plugin that adds a global memory layer: claude-memory-manager

It keeps memories in ~/.claude/memory/ and injects them at session start via a hook, so Claude doesn't start from zero. Global memories are shared across projects, so fixing a behavior once carries over everywhere. There's also a web UI for browsing and editing memory files, and export/import if you move between machines.

I hit the same wall running Claude Code on production projects. Spent months trying the usual workarounds: bigger CLAUDE.md files (adherence degrades past 200 lines, as the docs now acknowledge), manual session notes (works if you're disciplined, which I'm not at 11pm after a frustrating debug session), local MCP memory servers (cold start race conditions, Claude doesn't always reach for the tools, embedding models eating RAM across multiple terminals).

None of them solved the actual problem. They all store what the agent said and did. Conversational memory. But what a coding agent needs on a real project is project memory. The rules that exist regardless of any conversation. The architectural decisions and why they were made. The deployment warnings. The patterns every session should follow. That's a different kind of context and it needs structure, not semantic search.

So I built one. Minolith is a hosted API that stores typed, tagged, queryable project knowledge. 19 entry types (rule, decision, warning, pattern, event, workflow, etc.), tag-based filtering, priority levels. The agent queries it via MCP. Instead of loading a 500-line flat file and hoping attention lands on the right parts, the agent loads precisely what's relevant: high-priority rules at session start, CSS-specific patterns when doing frontend work, deployment warnings before shipping.

A few things that address specific points from this thread:
"Every session starts from zero." There's a bootstrap endpoint that returns the agent's identity, pre-loaded context entries, active procedure state, and open feedback counts in one call. The session starts with full project awareness before the first prompt.
"The value of an AI assistant compounds over time." Every rule, decision, and warning stored during development is available to every future session. New team members' agents get the same knowledge base. The project gets smarter over time because knowledge accumulates in a structured store instead of evaporating when the terminal closes.
"It should learn from corrections." When the agent discovers a gotcha or you correct a mistake, it stores a warning or rule entry via MCP immediately. That entry is tagged, prioritised, and available to every session going forward. No compression, no summarisation, no hoping the compaction summary preserves the detail.

Cross-machine, cross-tool. It's a hosted API. Start a session on your desktop, continue on your laptop. Works with Claude Code, or any MCP client. One command to connect:

claude mcp add --transport http minolith https://mcp.minolith.io \
  --header "Authorization: Bearer mlth_your_api_key"

Context operations cost zero credits on any plan. Beyond memory, the same MCP connection also gives the agent changelog publishing, user feedback collection, executable runbooks with persistent progress, agent identity management, and a structured design system API.

https://minolith.io/

The distinction between conversational memory (what happened in past sessions) and project memory (what the project needs every session to know) is the thing I think most solutions in this space are missing. Both are valuable. They solve different problems. The goldfish needs both, but project memory is the one that actually makes it stop repeating your mistakes.

This is the issue I wish I'd found before spending months building my own solution. The "it's a goldfish" framing is exactly right — and the contrast with claude.ai web (which does maintain memory) makes it feel like a deliberate product gap rather than a technical constraint.

Worth noting for anyone landing here: Anthropic did ship a native Session Memory feature (visible as "Recalled/Wrote memories" in the terminal around v2.1.30). It works on Pro/Max subscriptions and auto-generates structured summaries. But it has two hard limitations:

1. Not available on API/Bedrock/Vertex/Foundry — if you're using Claude Code through the API rather than a subscription, you get nothing
2. No semantic search — it injects structured summaries by recency, not by relevance to what you're currently working on. After 30+ days of daily use, the accumulated summaries start degrading session quality because there's no way to distinguish "still relevant" from "superseded"

For anyone hitting either of those walls, the hooks system is a workable bridge. A Stop hook blocks exit once, prompting Claude to write a summary. A UserPromptSubmit hook re-injects relevant context at the start of each message. Together they're a reasonable approximation of what a native system should do.

I've been running this setup for several months and open-sourced it at github.com/mnemopay/mnemopay-sdk — npx @mnemopay/sdk setup configures both hooks automatically and sets up an MCP memory server with semantic recall. It's not what a native implementation would be, but it fills the gap.

The deeper request — syncing with claude.ai memory so there's "one Claude, one memory, multiple interfaces" — is the one I most want to see. The current state where the web interface and the CLI are isolated memory silos doesn't make sense to users who use both.

I hit this exact wall and ended up building a full solution on top of Claude Code.

Tiered memory retrieval: recent sessions load instantly, semantic search (sqlite-vec) across all past conversations, and an atom layer that extracts discrete facts and surfaces them in future queries.
All local SQLite, cloud sync.

It also scores responses with a local Ollama judge and feeds corrections back into per-domain principles — so it doesn't just remember, it actually improves.

Open-sourced it today:
https://github.com/sliamh11/deus

~920 tokens added at session start (KV-cached). Per-turn overhead is zero for most interactions.

@minolith-devops the cold start race condition thing is real and it's the part that killed every local MCP approach I tried too. By the time the model's first tool call fires, the MCP server sometimes isn't ready yet — and even when it is, there's no guarantee the model reaches for memory tools before it starts doing actual work.

The approach that's been working for me: stop depending on the model to pull its own context and instead push it in at session start via the hooks system. Stop hook blocks exit until the summary writes. Session start hook injects the last summary before the model's first token. The model never has to decide to use memory — it just arrives already knowing.

I built this into MnemoPay (mnemopay.com) if you want to see the full implementation — the MCP server handles both the persistence layer and the session hooks. Would be curious what your cold start timing looked like, if it was consistent or only happened on the first connect.

@t49qnsx7qt-kpanks Your hook-based approach is solid for pushing context in. We took a different path with Minolith: the agent calls bootstrap as its first action and gets its identity, high-priority context entries, assigned tasks, recent team activity, and active state in a single response. It's not hook-dependent so there's no timing race. The context is hosted, not local, so there's no embedding model to warm up and no machine-bound state.
The trade-off is that it's an explicit tool call rather than automatic injection. But in practice, agents call bootstrap reliably because it's in the MCP tool list and the first response tells them everything they need to start working. We haven't seen the model skip it.

I built a Claude Code skill that tackles this — it extracts project-level knowledge (decisions, pitfalls, constraints) during
conversations and auto-recalls them in future sessions. Unlike CLAUDE.md (static rules) or auto-memory (personal preferences), it's
structured project memory with tiered importance and scope-based retrieval.

Repo: {know-for-agent}

Would love feedback from anyone hitting this problem.

Persistent memory would help a lot, but I think the useful shape is probably pretty small and explicit:

1. Keep the memory layer local + file-based so users can inspect, version, and reset it.
2. Separate durable facts/preferences from noisy session logs, otherwise retrieval quality collapses fast.
3. Make writes opt-in or rule-based, because automatic “remember everything” becomes clutter surprisingly quickly.

I ran into this enough that I built an open-source zero-dependency memory layer for Claude Code experiments: https://github.com/hilyfux/knowledge-graph

Not posting this as “the answer”, more as a concrete reference for what seems to work in practice: explicit entities/relations, lightweight retrieval, and human-readable storage. Even if Claude Code ships native memory, I think those design constraints still matter.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

v0.10.0 update: world-model-mcp's persistent-memory layer for Claude Code sessions now extends to six additional runtimes via adapters shipped in v0.10.0 (2026-07-01): Cursor, Codex, pi, OpenClaw, Hermes Agent, Continue. A project opened in multiple clients shares one SQLite fact graph across all of them — a fact captured in Claude Code is visible to Continue's agent mode and to OpenClaw's channel routing in the same project.

The v0.9 SWE-bench Verified benchmark tested whether persistent memory measurably reduces repeated coding-agent failures — result honestly bounded by the v0.9.2 multi-seed replication appendix (load-bearing replication 0/7, mean paired delta +0.24 per instance across two seeds, bootstrap 95% CI [0.00, 0.47]). The architectural wedge (lifecycle-hook capture, per-fact provenance, per-evidence-type decay, PreToolUse defer) survives the multi-seed update because it's architectural not empirical.

Repo: https://github.com/SaravananJaichandar/world-model-mcp — paper preprint at https://doi.org/10.5281/zenodo.20834508