No way to view, manage, or opt out of stored memories

[dilraj-dev]

Describe the bug

Memories stored via store_memory are scoped to the repository, not the user. There is currently no way for individual users to view, delete, or opt out of them.

The problem at scale

In large repos with many contributors, memories accumulate quickly. Our repo has hundreds of stored memories — many low-quality, duplicated, or originating from other users' sessions. As a user, I can see that some of these memories are surfaced in my sessions automatically, but I have no visibility into how they're selected, ranked, or shared.

We've actively seen model performance degrade due to low-quality and contradictory memories. An audit of our repo's ~310 memories found that only ~65% are accurate — meaning roughly 1 in 3 memories are wrong, duplicated, or misleading:

Category	Count (est.)	%
❌ Inaccurate	~30	10%
⚠️ Partially Accurate	~20	6%
🔁 Redundant Duplicates	~60	19%

Key findings:

• ~50 duplicate memories for a single rule ("never use as type casts"), ~15 of which incorrectly state the rule by prohibiting as const when it is explicitly allowed
• Mutually contradictory memories about git workflows (e.g. "always push without asking" vs "never auto-push") — none sourced from actual repo instructions
• One dangerous memory instructing the agent to "run shell commands immediately without discussion"
• Fabricated facts like hardcoded app IDs that are actually repository variables

Impact

• A 35% miss rate on system prompt instructions is unacceptable — it actively degrades model output
• Contradictory memories force the model to arbitrate between conflicting instructions
• Repo owners can delete memories, but manual cleanup doesn't scale — new low-quality memories are constantly added
• The only user-level workaround is "store a correcting fact," which just adds more entries

What's needed

1. User-level controls: View, delete, and opt out of memories (e.g. /memory list, /memory delete, /memory off)
2. Better repo-level tooling: Bulk management, dedup, and quality controls — not just the ability to delete one at a time
3. Better defaults: Automatic deduplication, expiry, quality gates, or a cap to prevent unbounded accumulation

Affected version

No response

Steps to reproduce the behavior

No response

Expected behavior

No response

Additional context

No response