making claude actually remember your code (and why that matters)

so there’s this thing i’ve been working on and playing around with lately - memory store. i’ve been using it for different tasks and it’s been honestly pretty fun. recently i built this memory plugin for claude code that’s made my workflow way better, and i wanted to share what it does and why it’s been useful.

quick context: i work at julep and we built memory.store, so yeah, this is built on our infrastructure. but the problem this solves is super real and i was kinda going insane before i figured it out.

the actual problem

i’ve been using claude code since it came out. it’s legitimately incredible for building things fast. but there’s this thing that kept driving me nuts.

every. single. session. starts. from. zero.

you know that feeling when you’re pairing with someone new and the first 30 minutes is just context dump? that’s every claude session. yesterday:

me: “hey we’re using oauth2 for auth” claude: builds perfect oauth2 implementation

today: me: “add a new endpoint” claude: “should we use JWT for authentication?”

me: screaming

like we JUST talked about this. it’s everywhere in the codebase. but claude can’t remember. sessions are completely isolated by design.

why i actually care about this

i’m not building todo apps. i’m working on autotelic (autonomous agent infrastructure), client projects with real business logic, tools that need to be maintained. context switching between projects is already brutal. having to re-explain architectural decisions every single time i open claude? i was spending more time explaining than coding.

and it’s not just “what framework.” it’s the WHY. we chose postgres over mongo because we need ACID compliance for financial transactions. that decision has 20 minutes of reasoning behind it. claude should know this.

where this came from

here’s the context: i work at julep. we built memory.store - basically a semantic memory system that works across conversations and tools. i’ve been using it for months for other stuff:

• tracking customer conversations
• building context for different ai agents
• keeping state across multiple tools

it’s been working really well for those use cases. but coding felt different. way more complex. more about patterns. “we ALWAYS do it this way, not that way.” corrections that should become rules.

i kept thinking: this memory architecture could solve the claude code problem. but it needs to be built specifically for development workflows. track file changes. detect patterns. capture business context. make corrections sticky.

so i built it. built the plugin using claude code itself, which was honestly pretty meta. memory store was helping me build the plugin that makes memory store work with claude code.

yeah so claude code has CLAUDE.md files. you put instructions in there for how claude should work on your project. they’re genuinely useful. i use them on every project.

but here’s the problem: they’re static. you write them once, they sit there. they don’t capture:

• “we tried approach X, it didn’t work, here’s why”
• “you suggested JWT yesterday, i corrected you to OAuth2, remember that”
• patterns that emerge over time
• business context that explains technical decisions

we also use anchor comments heavily in our code:

<!-- AUTH-FLOW -->
// OAuth2 implementation with refresh token rotation
// See CLAUDE.md for the security requirements

these help a LOT. they’re signposts. but they’re still just pointers to static docs. they don’t help claude learn from mistakes or remember corrections.

CLAUDE.md + anchor comments = good for “here’s how we do things”

memory store plugin = good for “remember we talked about this, you got it wrong, here’s the correction”

they work together. CLAUDE.md is your baseline documentation. memory store is the living context that accumulates as you work.

i’ve written detailed docs about all this in the GitHub repo. the README explains the anchor comment tracking, how CLAUDE.md files get synced to memory, how the whole system works together.

so i built something

the memory store plugin for claude code. basically makes claude remember your project.

how it works:

session starts → loads all your past decisions, patterns, corrections automatically

you’re coding → every file change gets tracked. patterns detected. business context captured.

every 10 changes → checkpoint. “hey is this matching what you wanted?” interactive validation.

you catch a mistake → /correct "we use oauth2 not jwt because xyz" → high priority memory. claude never forgets.

session ends → automatic feedback. rates the session. stores learnings. next time it’s smarter.

why this actually works (the technical bit)

okay so here’s what makes this different from just “save everything to a file.”

memory store uses vector embeddings + temporal weighting + importance scoring. when you do /correct "api routes should be plural (/users not /user). restful convention we follow" - that doesn’t just get logged somewhere. it gets:

1. embedded semantically - so when claude encounters any similar routing decision, this surfaces
2. marked as high importance - corrections automatically get priority over observations
3. tagged as resolution - is_resolution: true tells the system “this overrides a previous wrong belief”
4. temporally weighted - recent corrections matter more than old ones, but they don’t disappear

next session when claude’s building something similar, that correction surfaces during the context retrieval at session start. it’s not searching for exact text matches. it’s semantic. claude sees routing patterns → memory system returns your routing conventions.

the magic is in the recall system. it’s not just searching for keywords. it’s understanding what kind of decision is being made right now and surfacing relevant past decisions from your history.

this is why memory store works for this and a simple log file doesn’t. coding has patterns that repeat across different syntax. “use plural routes” applies whether you’re writing express, fastapi, or rails. semantic memory catches that.

the actual experience

before this existed:

• open claude code
• spend 10 minutes explaining architecture
• explain patterns (“we use X style for Y”)
• claude makes something wrong
• correct it
• next day: claude suggests the wrong thing again
• realize you’re in groundhog day
• wonder why you’re not just writing it yourself

now:

• open claude code
• it already loaded your past corrections, patterns, decisions
• suggests something that matches your actual codebase style
• makes a mistake (still AI)
• you correct it once with /correct
• next session it doesn’t make that mistake
• actually feels like pairing with someone who’s been on the project

the difference is: claude stops being the intern who needs everything explained every morning. starts being the person who actually knows your project.

the validation stuff (unexpectedly useful)

here’s something i didn’t plan to care about but ended up loving.

every 10 file changes, the plugin stops and goes:

checkpoint: i've made 10 changes

completed:
✓ oauth2 setup
✓ api endpoints
✓ middleware

in progress:
⏳ tests

is this matching your expectations?

why this matters: catches mistakes EARLY. before you commit. before you realize claude went down a completely wrong path 50 files ago and now you’re in refactor hell.

i’ve had sessions where claude was doing great for 8 files, then file 9 was slightly wrong, and i caught it at the checkpoint. saved me from having claude build on top of a wrong assumption.

also pre-commit validation: shows you what’s about to be committed, scans for secrets (has saved me from committing API tokens TWICE), checks for leftover debug code, console.logs, etc.

is it perfect? no. have i still committed dumb things? yes. but it’s way better than not having it.

why this is actually different (and why it matters)

here’s what i’ve learned building this: memory store was already good for tracking conversations and general context. we use it at julep for agent conversations, customer interactions, multi-tool workflows. it works really well for that.

but coding is DIFFERENT. it’s not just “remember what we talked about.” it’s:

• patterns that should be enforced (“we always do X, never Y”)
• corrections that should become rules (“you got this wrong, here’s why”)
• business context that explains technical decisions (“we use postgres because ACID compliance for financial data”)
• architectural decisions that should persist (“microservices pattern with event sourcing”)

this plugin bridges that gap. makes memory store work specifically for development workflows. tracks file changes. categorizes them (feature, bugfix, refactor, config). detects patterns. makes corrections sticky.

what actually changed in my workflow:

before	after
re-explain architecture every session	loads automatically with context
claude suggests wrong patterns	learns from corrections, stops suggesting them
business context lost between sessions	”why” persists, not just “what”
no feedback loop	session ratings surface what’s working
repeat same corrections	correct once, it sticks

the honest limitations

this is early. like, i just built this. some things that are still rough:

• first 2-3 sessions are just building context. it’s not magic immediately.
• you need memory store access (beta, there’s a waitlist)
• if you don’t correct claude, it won’t learn. you have to use /correct actively.
• works way better on projects you work on regularly vs one-off scripts
• the checkpoints can be annoying if you’re on a roll (working on making them smarter)

memory store is beta. waitlist at memory.store. the plugin is live though, works today if you have access.

why this actually matters

here’s the thing: ai pair programming is incredible but it’s fundamentally limited by memory. every session starting from zero means:

• you’re re-explaining instead of building
• claude can’t learn from mistakes
• patterns don’t stick
• business context doesn’t persist

this isn’t just convenience. it’s the difference between “claude is a tool i use sometimes” and “claude is actually part of my development workflow.”

i’ve been using this for autotelic work for a few weeks now. claude knows our agent architecture. knows we use temporal for orchestration. knows our API patterns. knows our testing conventions. i spend way less time explaining and way more time actually building.

is it perfect? no. ai is still AI. but it’s way closer to actually having persistent context across work sessions.

try it if you have memory store access. tell me what breaks. tell me what’s useful. tell me what’s stupid. i’m figuring this out as i go.

---

getting started (if you want to try this)

first: you need memory store access. it’s in beta. join waitlist at memory.store. they’re letting people in regularly but it’s not instant.

once you have access:

# in claude code
/plugin marketplace add julep-ai/memory-store-plugin
/plugin install memory-store

# configure your api key (you'll get this with memory store access)
# then just... start working

that’s it. the plugin hooks into claude code automatically. tracks file changes, gives you checkpoints, lets you use /correct for corrections.

for detailed setup instructions, see the full docs on GitHub. covers token config, team setup, CLAUDE.md integration, anchor comment tracking, everything.

what to expect:

• first session: mostly just tracking. building initial context.
• sessions 2-3: starting to see patterns. still building context.
• session 4+: claude starts loading relevant context automatically. you’ll notice it remembering things you never explained this session.

how to actually use it:

• work normally with claude code
• when claude gets something wrong: /correct "explanation of what's wrong and why"
• every 10 changes: checkpoint will ask if things look good
• end of session: quick rating (helps improve things)

that’s the workflow. it’s pretty low-friction once you get used to it.

final notes

this is my attempt at solving a real problem. i work at julep, we built memory.store, i used it to solve the claude code memory problem. is it self-promotion? yeah kinda. is the problem real and the solution useful? i think so. you can decide for yourself.

the code is open source. the plugin is live. full docs at github.com/julep-ai/memory-store-plugin.

if you try it and it’s broken or stupid or missing something obvious, open an issue or tell me. i’m trying to make this actually useful, not just ship something and disappear.

read the full docs if you want details:

• how anchor comments get tracked
• how CLAUDE.md files sync to memory
• how the validation system works
• how to set up with your team
• examples and best practices

---

written during a session where claude and i paired on this blog post. session rating: honestly probably an 8/10. had to correct a few things. but those corrections are now in memory, so next time will be better. which is kind of the whole point.