feat : add auto container tags feature to claude supermemory

[ved015]

Summary

This PR introduces Auto Container Tags allowing users to define custom memory buckets (e.g., work, personal, code_style) and giving the AI the ability to intelligently route memories to specific containers based on plain-English descriptions and doesnt just bulk a single space with everything

---

Claude use the specific containe tag to search and retrieve memories it also adds memory and routes to the specific container itself

Claude memories saved alongside with codex memories in the code_preferences container

Work and code_preferences space created on the dashboard

[vorflux]

Reviewed the auto container tags feature. A few issues to address -- see inline comments.

---

Review with Vorflux

[ved015]

@claude pls review this

[claude]

Claude finished @ved015's task in 2m 52s —— View job

---

PR Review: Auto Container Tags Feature

Tasks:

• Gather context and understand the request
• Read changed files
• Analyze code quality, bugs, and best practices
• Post review feedback

---

Overview

This PR adds a solid, well-structured feature for routing memories to named containers. The implementation is clean overall. I also verified that most of the issues raised in the vorflux review have already been addressed in the fix: address PR review comments commit — good follow-through.

---

Previously Raised Issues (Vorflux Review) — Status Check

Issue	Status
Duplicate config-loading logic → extract getResolvedContainers	✅ Fixed — settings.js:139 has the shared helper
Inconsistent errorNotice in context-hook.js	✅ Fixed — both branches now consistently show error + no-memories message
\s* → \n* in summary-hook.js regex	✅ Fixed — both regexes now use \n*
parseArgs duplication → parse-args.js	✅ Fixed — src/lib/parse-args.js added
Misleading client default tag in search-memory.js	⚠️ Still present (minor, noted below)

---

New Issues Found

1. Medium — Auto-save in summary-hook.js ignores container routing

src/summary-hook.js:82-95 always saves session memories to the default personal container (getContainerTag(cwd)), regardless of any custom container configuration. The feature strips <supermemory-containers> sections from content (lines 65-74) but never uses container config to route where the content goes.

// summary-hook.js:82-84 — always saves to default personal tag
const containerTag = getContainerTag(cwd);
// ...
await client.addMemory(cleanedContent, containerTag, ...);

The feature description promises "intelligently route memories to specific containers" — but the auto-save on session stop doesn't do this. Only explicit /add-memory --container <tag> calls are routed. This is a functional gap worth documenting or addressing.

Fix this →

---

2. Minor — Duplicate container entries possible in getResolvedContainers

src/lib/settings.js:150 merges global and project containers without deduplication:

const containers = [...globalContainers, ...projectContainers].filter(...)

If the same tag appears in both global and project config, it will be listed twice in the catalog shown to Claude and validated twice (both would pass). Consider deduplicating by tag, letting project config override global:

const allContainers = [...globalContainers, ...projectContainers];
const seen = new Set();
const containers = allContainers.filter(c => {
  if (!c || typeof c.tag !== 'string' || typeof c.description !== 'string') return false;
  if (seen.has(c.tag)) return false;
  seen.add(c.tag);
  return true;
});

Fix this →

---

3. Minor — Redundant tag argument in add-memory.js

src/add-memory.js:49-54 passes effectiveTag to both the SupermemoryClient constructor and to client.addMemory():

const client = new SupermemoryClient(apiKey, effectiveTag); // sets default tag
const result = await client.addMemory(content, effectiveTag, ...); // overrides it anyway

Same pattern exists in save-project-memory.js:49-54. If addMemory always takes the tag explicitly, the constructor argument is redundant (it's used as a "default" but never falls back to it). Worth either removing it from the constructor call or documenting why both are needed.

---

4. Minor — Still misleading in search-memory.js:57-58 (vorflux noted this)

const defaultTag = containerType === 'custom' ? containerTag : personalTag;
const client = new SupermemoryClient(apiKey, defaultTag); // sets containerTag as default...
// ...
const result = await client.search(query, containerTag, ...); // ...but never uses it

In the custom path, containerTag is passed to both constructor and client.search(). The constructor default is dead code in this path. Simple fix: just pass personalTag to the constructor always (since the search explicitly specifies the tag in every call anyway).

Fix this →

---

5. Informational — No test coverage for new logic

The container validation, resolution, and catalog generation in src/lib/settings.js are pure functions that are straightforward to unit test. No tests were added. Given the feature relies on these returning correct results to route memories correctly, this is worth noting.

---

What Works Well

• The getResolvedContainers shared helper is clean and eliminates duplication
• Container validation with user-friendly error messages is a nice UX touch
• The parse-args.js extraction is the right call
• Injecting the container catalog into session context so Claude can intelligently route is an elegant approach
• The regex fix (\n* instead of \s*) is correct and prevents content corruption

---

Overall this is a solid, well-motivated feature. The main concern worth addressing before merge is clarifying the auto-save limitation in summary-hook.js — either implement auto-routing for session-stop saves or document clearly that only explicit /add-memory --container calls are routed.

[ved015]

@MaheshtheDev i have fixed the suggestions its ready for another round of review

[MaheshtheDev]

don't we need to update the package version?

[ved015]

don't we need to update the package version?

Yes done!