Show HN: Stop Claude Code from forgetting everything (github.com)

202 points by austinbaggio ↗ HN
I got tired of Claude Code forgetting all my context every time I open a new session: set-up decisions, how I like my margins, decision history. etc.

We built a shared memory layer you can drop in as a Claude Code Skill. It’s basically a tiny memory DB with recall that remembers your sessions. Not magic. Not AGI. Just state.

Install in Claude Code:

  /plugin marketplace add https://github.com/mutable-state-inc/ensue-skill
  /plugin install ensue-memory
  # restart Claude Code
What it does: (1) persists context between sessions (2) semantic & temportal search (not just string grep). Basically git for your Claude brain

What it doesn’t do: - it won’t read your mind - it’s alpha; it might break if you throw a couch at it

Repo: https://github.com/mutable-state-inc/ensue-skill

If you try it and it sucks, tell me why so I can fix it. Don't be kind, tia

68 comments

[ 2.1 ms ] story [ 73.6 ms ] thread
(comment deleted)
I mostly use it during long Claude Code research sessions so I don’t lose my place between days.

I run it in automatic mode with decent namespacing, so thoughts, notes, and whole conversations just accumulate in a structured way. As I work, it stores the session and builds small semantic, entity-based hypergraphs of what I was thinking about.

Later I’ll come back and ask things like:

what was I actually trying to fix here?

what research threads exist already?

where did my reasoning drift?

Sometimes I’ll even ask Claude to reflect on its own reasoning in a past session and point out where it was being reactive or missed connections.

Thank you for specifying it wasn't magic or AGI.
I absolutely love this concept! It's like the thing that I've been looking for my whole life. Well, at least since I've been using Claude Code, which is this year.

I'm sold.

With that said, I can't think of a way that this would work. How does this work? I took a very quick glance, and it's not obvious at first glance.

The whole problem is, the AI is short on context, it has limited memory. Of course, you can store lots of memory elsewhere, but how do you solve the problem of having the AI not know what's in the memory as it goes from step to step? How does it sort of find the relevant memory at the time that that relevance is most active?

Could you just walk through the sort of conceptual mechanism of action of this thing?

What is the advantage over summarizing previous sessions for the new one?

Or, over continuing the same session and compacting?

maybe you are in a claude code session and think "didn't i already make design doc for system like this one?" Or you could even look at your thought process in a previous session and reflect. but rn i mainly use it for reviewing research and the hypergraph retrieval
What's the data retention/deletion policy and is there a self-hosted option planned? I'd prefer not to send proprietary code to third-party servers.
+1 to beads. Works great
Beads is awesome. I've been using it with a greenfield React Native hobby project. I did some work up front on the spec (with help from AI), and started the repo from a boilerplate, but after that every single bead (epic, ticket) and every single line of code has been written by AI (using a mix of claude, codex, cursor-agent/composer-1).

The app works. When I feel like working on it, I just open a CLI coding agent and say 'start working'. Then every so often I say 'commit and push' or 'find opportunities to improve the code base by refactoring, and create an issue for each opportunity'.

(I followed the instructions to add the boilerplate instructions for both bd and bv, to AGENTS.md)

(comment deleted)
Is anyone else just completely overwhelmed with the number of things you _need_ for claude code? Agents, sub agents, skills, claud.md, agents.md, rules, hooks, etc.

We use Cursor where I work and I find it a good medium for still being in control and knowing what is happening with all of the changes being reviewed in an IDE. Claude feels more like a black box, and one with so many options that it's just overwhelming, yet I continue to try and figure out the best way to use it for my personal projects.

Claude code suffers from initial decision fatigue in my opinion.

I just ask Claude to look at past conversations where I was working on x… it sometimes thinks it can’t see them, but it can.

I’ll give this a go though and let you know!

I don't understand the use case. I think if you don't use agents, and skills currently effectively, then perhaps this is useful.

If you're using them though, we no longer have the problem of Claude forgetting things.

That makes sense, and I agree that for a single agent using skills well, Claude’s native context handling has gotten much better.

This wasn't mentioned in the first post, but the use case we’re focused on isn’t really “Claude forgetting,” but context living beyond a single agent or tool. Even if Claude remembers well within a session, that context is still owned by that agent instance.

The friction shows up when you switch tools or models (Claude → Codex / Cursor / etc.), run multiple agents in parallel, or want context created in one place to be reused elsewhere without re-establishing it.

In those cases, the problem isn’t forgetting so much as fragmentation. If someone is happy with one agent and one tool, there are probably a bunch of memory solutions to choose from. The value of this external memory network that you can plug into any model or agent shows up once context needs to move across tools and people.

Your site advertises careers in San Francisco/Remote. California law requires compensation disclosures.
Non starter for us, we cant ship propriety data to a third party servers.
I struggle with these abstractions over context windows, esp when anthropic is actively focused on improving things like compaction, and knowing the eventual* goal is for the models to yave real memory layers baked in. Until then we have to optimize with how agents work best and ephemeral context is a part of that (they weren’t RL’d/trained with memory abstractions so we shouldn’t use them at inference either). Constant rediscovery that is task specific has worked well for me, doesn’t suffer from context decay, though it does eat more tokens.

Otherwise the ability to search back through history is a valuable simple git log/diff or (rip)grep/jq combo over the session directory. Simple example of mine: https://github.com/backnotprop/rg_history

There's a lot of people interested in forming some sort of memory layer around vendored LLM services. I don't think they realize how much impact a single error that disappears from your immediate attention can have on downstream performance. Now think of the accrual of those errors over time and your lack of ability to discern if it was service degradation or a bad prompt or a bad AGENTS.md OR now this "long term memory" or whatever. If this sort of feature will ever be viable, the service providers will offer the best solution only behind their API, optimized for their models and their infrastructure.
There are a quadrillion startups (mem0, langmem, zep, supermemory), open source repos (claude-mem, beads), and tools that do this.

My approach is literally just a top-level, local, git version controlled memory system with 3 commands:

- /handoff - End of session, capture into an inbox.md

- /sync - Route inbox.md to custom organised markdown files

- /engineering (or /projects, /tasks, /research) - Load context into next session

I didn't want a database or an MCP server or embeddings or auto-indexing when I can build something frictionless that works with git and markdown.

Repo: https://github.com/ossa-ma/double (just published it publicly but its about the idea imo)

Writeup: https://ossa-ma.github.io/blog/double

Just put a claude.md file in your directory. If you want more details about a subdirectory put one in there too.

Claude itself can just update the claude.md file with whatever you might have forgot to put in there.

You can stick it in git and it lives with the project.

stop wasting context space with this stuff ミ · · 彡
> Not magic. Not AGI. Just state.

Why did you need to use AI to write this post?

This is impressive.

Though I have found repo level claude.md that is updated everytime claude makes a mistake plus using —restore to select a previous relevant session works well.

There is no way for Anthropic to optimize Claude code or the underlying models for these custom setups. So it’s probably better to stick with the patterns Anthropic engineers use internally.

I like it when the conversation is new sometimes.
I'm not sure how many HN users frequent other places related to agentic coding like the subreddits of particular providers, but this has got to be the 1000th "ultimate memory system"/break-free-of-the-context-limit-tyranny! project I've seen, and like all other similar projects there's never any evidence or even attempt at measuring any metric of performance improved by it. Of course it's hard to measure such a thing, but that's part of exactly why it's hard to build something like this. Here's user #1001 that's been told by Claude "What a fascinating idea! You've identified a real gap in the market for a simple database based memory system to extend agent memory."
Some with a coding background love prompt engineering, contrived supporting systems, json prompting and any other superstition that makes it feel like they're really doing something.

They refuse to believe that it's possible to instruct these tools in terse plain English and get useful results.

This is fair, many memory projects out there boil down to better summaries or prompt glue without any clear way to measure impact.

One thing I’d clarify about what we’re building is that it’s not meant to be “the best memory for a single agent.”

The core idea is portability and sharing, not just persistence.

Concretely:

- you can give Codex access to memory created while working in Claude

- Claude Code can retrieve context from work done in other tools

- multiple agents can read/write the same memory instead of each carrying their own partial copy

- specific parts of context can be shared with teammates or collaborators

That’s the part that’s hard (or impossible) to do with markdown files or tool-local memory, and it’s also why we don’t frame this as “breaking the context limit.”

Measuring impact here is tricky, but the problem we’re solving shows up as fragmentation rather than forgetting: duplicated explanations, divergent state between agents, and lost context when switching tools or models.

If someone only uses a single agent in a single tool and already are using their customized CLAUDE.md, they probably don’t need this. The value shows up once you treat agents as interchangeable workers rather than a single long-running conversation.

Doesn't Claude already use RAG on the backend?