Claude Code Memory: How to Give Claude Persistent Context Across Projects
Claude Code forgets everything when a session ends. Here's how to give it persistent memory across projects using MemClaw — no re-explaining your codebase every session.
You open Claude Code. You explain your architecture. You describe the bug. You get a great answer.
You close the session.
Tomorrow, you do it all again.
This is the core frustration with Claude Code — not the quality of its answers, but the fact that it starts from zero every single time. No memory of your codebase. No memory of decisions you made last week. No memory of the three hours you spent explaining why you chose that database schema.
This guide covers exactly how to fix that.
Why Claude Code Has No Memory
Claude Code operates within a context window — a fixed amount of text it can process at once. When a session ends, that window closes. Nothing carries over.
For a quick one-off task, this is fine. For ongoing development work, it creates real friction:
- Re-explaining architecture every session wastes 10–15 minutes before you get to actual work
- Switching between projects means manually loading different context each time
- Long-running decisions — why you chose library X over Y, why that function is structured that way — live only in someone's head
- Team handoffs require someone to reconstruct context that already existed somewhere
This isn't a bug. It's how stateless systems work. But it's fixable.
What "Claude Code Memory" Actually Means
When developers search for "claude code memory," they're usually looking for one of three things:
Session persistence — resuming a conversation where it left off. Claude Code doesn't support this natively. Each session is independent.
Project context — having Claude understand your codebase without re-explaining it every time. This is solvable.
Cross-project isolation — keeping context for Project A completely separate from Project B. This is what MemClaw is built for.
The Partial Fix: CLAUDE.md
The simplest approach is a CLAUDE.md file in your project root. Claude reads it at session start:
# Project: MyApp
## Stack: Next.js 14, TypeScript, PostgreSQL
## Key decisions: JWT for auth, REST API conventions
## Current focus: Auth refactor (started 2026-03-20)
This works for a single project. The limits show up quickly:
- Single flat file — no structure, no search
- Static — you maintain it manually, it goes stale
- No history — decisions made six months ago aren't tracked
- No isolation — one file for everything, no per-project separation
- Not queryable — Claude can't answer "what did we decide about caching last month?"
For a solo developer on one small project, CLAUDE.md is often enough. For anything more complex, you need something better.
The Persistent Fix: MemClaw
MemClaw gives Claude Code persistent project memory. Each project gets its own isolated workspace that accumulates context over time — decisions, status, artifacts, background context.
Install MemClaw on Claude Code:
/plugin marketplace add Felo-Inc/memclaw
/plugin install memclaw@memclaw
Set your API key:
export FELO_API_KEY="your-api-key-here"
Get your key at felo.ai/settings/api-keys.
Create a workspace per project:
Create a workspace called MyApp
Add your project context once:
Add to workspace: Next.js 14 + TypeScript + PostgreSQL.
Auth uses JWT in httpOnly cookies — security team requirement.
Currently refactoring the auth middleware to extract JWT validation.
Main contact: Sarah ([email protected]). Q2 deadline.
Load at the start of every session:
Load the MyApp workspace
Claude reads the workspace and is immediately oriented — no re-explaining needed.
Real Scenarios Where This Matters
Picking up after a week away:
Load the MyApp workspace
Where did I leave off on the auth refactor?
Claude reads the workspace and tells you exactly where things stand — because you logged the status at the end of your last session.
Freelancer with multiple clients:
Load the Acme workspace
→ Claude has Acme context only
Load the Beta Corp workspace
→ Claude switches to Beta Corp. Acme is gone from the picture.
Each client gets their own workspace. Zero cross-contamination. This is the scenario MemClaw is built for.
Team handoff: Share the workspace with a new developer. They load it and Claude already knows the project history, the decisions that are off the table, and where things currently stand. No 90-minute knowledge transfer call.
Logging decisions as you make them:
Add decision to workspace: using Postgres over MySQL because
the client's DBA only supports Postgres. Not negotiable.
Six weeks from now, Claude won't suggest switching to MySQL with a compelling argument. It knows the decision is locked.
MemClaw vs. Other Approaches
| Approach | Pros | Cons |
|---|---|---|
| CLAUDE.md | Zero setup, version-controlled | Static, no history, single file, no search |
| Manual context paste | Works anywhere | 10–15 min per session, easy to forget things |
| MemClaw | Persistent, searchable, isolated per project, team-shareable | Requires Felo API key |
For a single small project with a short lifespan: CLAUDE.md is fine.
The tipping point for MemClaw: multiple projects, or a project longer than a month, or a team of more than one person.
Getting Started
- Install MemClaw (memclaw.me)
- Create one workspace per active project
- Add baseline context — stack, key decisions, current status
- Load the workspace at the start of every session
- Log decisions and status updates as you work
The memory compounds. After two weeks, Claude starts answering questions from the workspace instead of asking you to re-explain. After a month, you stop thinking about context management entirely.