Feature Request: Persistent Memory Between Claude Code Sessions

[sudoxreboot]

Problem

Claude Code starts every session with zero context. There is no memory of previous sessions, previous work, or accumulated understanding of the user's projects and preferences.

Current Behavior

• Each claude invocation starts completely fresh
• No awareness of yesterday's work
• No memory of decisions made in previous sessions
• User must re-explain context every time
• CLAUDE.md helps but is manual and limited

Contrast with claude.ai

The claude.ai web interface maintains:

• User memories (preferences, context, personal info)
• Conversation history
• Project knowledge accumulated over time
• Understanding built through repeated interaction

Claude Code has none of this. It's a goldfish.

Impact

• Repeated context setup wastes time
• Nuanced understanding from past sessions is lost
• Can't build on previous work naturally
• The relationship doesn't compound over time
• Users maintaining CLAUDE.md manually is tedious and incomplete

Proposed Solutions

1. Local Persistent Memory

• Claude Code maintains its own memory store between sessions
• Learned preferences, project context, conventions
• Stored locally in ~/.config/claude-code/memory/
• User can view/edit/clear

2. Session Continuity

• Option to continue a previous Claude Code session
• claude --continue or claude --session <id>
• Resume where you left off

3. Sync with claude.ai Memory (see related issue)

• Pull from the same memory system as claude.ai
• One Claude, one memory, multiple interfaces

Why This Matters

The value of an AI assistant compounds over time. Every session that starts from zero wastes that compounding. Users paying for Claude expect continuity across the product, not amnesia in the CLI.

---

Alternatively, if these fixes are not feasible in the short term, update your ToS to allow subscribers to access their own sessions programmatically. This would let users build tools that work while these issues are addressed. Paying $200/mo for a product we can't reliably use, with no workaround permitted, is not acceptable.

[github-actions]

Found 3 possible duplicate issues:

1. Feature Request: Claude Code Should Access User's claude.ai Memory and Context #14228
2. Persistent session context across restarts #12990
3. Feature Request: Session Handoff / Continuity Support #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

[amarodeabreu]

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.

[sudoxreboot]

@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.

[RodrigoLuglio]

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.

[sudoxreboot]

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?

[RodrigoLuglio]

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.