Problem
Currently the plugin uses a single containerTag for all memories, set at initialization. Every memory stored and recalled shares the same container, regardless of context or sensitivity.
This becomes a problem when:
- Group chats vs private DMs: Sensitive personal memories can surface in group conversations
- Data imports (e.g., Instagram, contacts): Imported data has no way to be isolated from general conversation memories
- Multi-context usage: Project-specific memories leak into unrelated sessions
Supermemory already supports this
The Supermemory API supports containerTags for both add() and search() operations (docs). The plugin just doesn't expose this capability.
Proposed Solution
1. Add optional containerTag parameter to store tool
supermemory_store(text, category, containerTag?)
If omitted, uses the default tag (current behavior). If provided, stores to that specific container.
2. Add optional containerTag parameter to search tool
supermemory_search(query, limit?, containerTag?)
If omitted, searches the default container. If provided, searches that specific container.
3. Session-aware container selection (stretch goal)
The plugin could automatically select containers based on session context:
private — only surface in owner-only sessions
shared — safe for group chats
import:{source} — imported data with explicit access rules
4. Auto-capture tagging
When autoCapture stores memories, it should tag them based on the session type (DM vs group, which channel, etc.) so they can be filtered on recall.
Use Cases
- Keep personal data private in group settings
- Safely import external data (social media exports, contacts) without it leaking into conversations with others
- Project-specific memory isolation
- Compliance with user privacy expectations
Current Workaround
Calling the Supermemory API directly with different container tags, bypassing the plugin entirely — which defeats the purpose of having a plugin.