Comment by Kiro
2 days ago
> Now: Auto-memory
Not Claude Code but I just had a task where it started referring another conversation that was complete nonsense and throwaway. I absolutely don't want things to get added to some memory behind my back.
A big reason I use LLMs is because I can try out wild ideas and then just throw it away. I don't want those to pollute the context.
Same. I’m starting to believe that consumers need to own the UI/experience, so we can install blast doors around context/memory for each “slice” of our lives - something only we can know how to divide (imo). If the provider tools’ memory implementations can’t provide this multi-tenancy - or won’t because they want to Know Us, then we need to treat them as token vendors at best and adversaries at worst.
This would actually work very well - until context goes into latent space, becomes a server-side resource, and we lose sovereignty over our data. Tools like Pi and Openclaw are showing that other options exist to decouple us from the LLM provider frontend experiences, not just for orchestration and use case diversity but for pluggable memory designs.
Claude Code was writing one-off details (specific to one task) as memories, so I instructed it that memories require explicit approval before writing, and that seems to work reasonably well. That said, in my experience, Claude gets overly attached to the context, and will follow them even when irrelevant, or will often mention some mostly irrelevant detail from the context as if I asked for it explicitly in my prompt.
I leave Claude memory stuff turned off by default for the same reason. It inevitably ends up dragging in things that are unrelated and unimportant to the current task.
Claude Code gives you more control - you can disable auto-memory temporarily (nothing will be deleted), then enable it back; or you can setup a directory where auto-memory is disabled and do your throwaway there.
I had to add a reference in my system prompt on the app to not do things like this.