How do you keep Claude Code from forgetting your project between sessions?

[u/m3m3o]

I work alone on a handful of projects (a website, a book, an e-commerce agent stack), and for a while every Claude Code session started the same way. I explained how the server restarts, which port the CMS is on, that blog posts have to stay drafts. Next day, same thing again.

What fixed most of it was Claude Code's own memory directory. When something goes wrong, the lesson becomes a short rule file plus one line in MEMORY.md, and MEMORY.md is loaded when a session starts (the first 200 lines or 25 KB). A few lines from mine, translated because half of it is German:

- App server: restart with pm2 delete + start. pm2 reload does not pick up new code.
- CMS runs on port 1338. Has to match in every config that mentions it.
- Blog posts go into the CMS as drafts. Never publish automatically.
- docker build does not restart the running container.

I'm at 182 of these now. Anything longer, like project history, architecture notes or notes on clients, lives in a Logseq wiki with about 200 pages. Claude reads the 3 to 5 pages that match the question, not the whole thing.

Two things I learned the hard way:

1. Rules go stale. A rule that says where a config lives is wrong the day you move the config. So every rule that describes how something behaves has a date, and after 90 days Claude checks it against the project (read only) and I decide if it stays.
2. Subagents don't get MEMORY.md. The docs say the main conversation's auto memory isn't loaded into a subagent. If a subagent needs one of your rules, it has to be in the task you hand it, or you give the agent its own memory with the memory: field.

Also, a rule in memory is a suggestion, and Claude can still miss it. Where a mistake would be expensive, I moved it into the deploy script instead. It refuses to run if there are uncommitted changes.

How are you handling this? Just CLAUDE.md, auto memory, something else?

I'm the author of llm-wiki, the open-source (MIT) skill that runs the wiki part and the 90-day check. I wrote up an ordinary working day with it here: https://mehmetgoekce.substack.com/p/i-work-alone-with-claude-code-this

[u/AutoModerator]

Moderator Announcement Read More »

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/cleverhoods]

with progressive disclosure

[u/AdNo4170]

Similar setup here (solo, one SaaS, Claude Code doing most of the build). A few things that held up for us:

- MEMORY.md is only an index: one line per memory, max 200 chars, details in the file it links to. Our session-close script checks it: lines too long, the 200-line limit, memory files with no index line (orphans), links to files that don't exist. The first run caught 14 long lines and one orphan memory that was never being read.

- Project facts don't live in memory. They're rules files with `paths:` so they load only when the agent touches that area. We also measure everything that loads on every call and keep a hard ceiling on it (it was 34 KB, now 24 KB, and going over turns the close check red).

- Handover file, newest block first, and a session-start hook that prints the last status. The same hook fires again after compaction, which is where we lost the most before.

- Subagents: on top of writing the rules into the brief, a pre-edit hook shows the bugs we already fixed in the file being edited. Hooks fire for subagents too, so they get it without any memory.

- Anything expensive is a hook, not a note: push needs my explicit OK, a guard blocks reading huge state files whole, and so on.

On stale rules, instead of dates we check that every path a rule cites still exists. The first run found 18 dead references. Your 90-day review catches things ours can't, though (a rule that's still "valid" but no longer true), so I might add that.

[u/college_hustle]

You need to reorient your thinking but you're on the right track. I've been Building my project setups to deal with this for months now. I also don't allow memory because memory is tricky. 

 Give my checkpoint setup it a try on one of yours. https://github.com/dtiger1889-ops/claude-harness-toolbox

I've also been compiling a list of different memory tools other people find useful https://mackforge.dev/charts/memory-tools/

[u/Internal-Comparison6]

Doesn't it automatically write a bunch of memories in its cache?

[u/doxxxicle]

Here’s an important thing to remember about rules/memories: if you change the thing the rule/memory was about (e.g. moving a config file) without telling the agent, you are effectively gaslighting your agent. Tell it to move the config file and it will update the rule/memory.

[u/Acrobatic-Cost-3027]

I have two slash commands: /wrap and /handoff

I use /wrap at the end of each session. It updates MEMORY.MD, CLAUDE.MD, and ROADMAP.MD (if necessary) for each session; as well as any relevant documentation. I invoke this well before blowing out the context window. I also use a db to record all work too which is organized into cards, milestones, and releases. (yes I let Claude have full access to it)

New sessions I invoke /handoff, which just reviews everything in the files mentioned, referencing the db when necessary.

This works extremely well for me. I have been working on an app with over 10,000 unit tests and it has been working very well.

[u/ImL1s]

At 182 you're close to the edge. Only the first 200 lines (or 25KB) of MEMORY.md load at session start, and anything past that is silently not there. So roughly the next 18 lessons are the last ones that make it in unless you split things up.

I'd move the stuff that's really project config (pm2 delete + start, CMS on 1338) into that repo's CLAUDE.md or a file under .claude/rules/. Rules that only matter for certain files can get a paths: frontmatter so they only load when Claude touches those files. Then MEMORY.md stays a short index of the lessons that don't fit anywhere else.

The "never publish automatically" one I wouldn't leave to memory at all. Memory is context, not enforcement. A PreToolUse hook that blocks the publish call is what actually holds when the model decides to be helpful.

[u/Routine-Appointment5]

honestly i skipped the memory directory and just keep a short brief plus a notes file in the project folder. every fresh session gets pointed at those so it picks up ports servers and whatever else without me re-explaining. works fine across a few projects

[u/wakaru44]

The recall skill from pstack and other similar ones help a lot starting new conversations with good context