fix(tools): make claude memory customId injective to stop silent file overwrites

[Sravanjangam]

Fixes #1547.

Hi supermemory team 👋 Thanks for building such a great product! While running a security & quality audit of the repo we hit this issue and put together a small, tested fix — details below.

Problem

ClaudeMemoryTool.normalizePathToCustomId flattened / and . to _ non-injectively: /memories/notes.txt, /memories/notes_txt, and /memories/notes/txt all mapped to memories_notes_txt. Creating, viewing, or deleting one path therefore silently operated on a different file's document — silent data loss with no error surfaced.

Solution

Exported pure pathToCustomId() keeps the exact legacy id for the canonical single-segment shape (no underscore, exactly one dot, exactly one slash — e.g. /dir/file.ext) so already-stored documents keep resolving with zero migration, and appends an 8-hex sha256 digest of the original path for every other shape, making distinct paths map to distinct IDs again.

Changes

• packages/tools/src/claude-memory.ts → private method now delegates to the new exported pathToCustomId() (all six call sites covered)
• packages/tools/src/claude-memory.test.ts → +4 tests: three-way collision from the issue, legacy-id stability, determinism, distinct digests for distinct underscore paths

Verification

Fresh from the committed branch: bunx vitest run src/claude-memory.test.ts → 14/14 pass. packages/tools/test/** carries pre-existing type errors unrelated to this change (tracked in #1545) — this diff adds none.

---

Happy to iterate on any of this — feedback and reworks very welcome! 🙏

Environment

• macOS 26.1 (arm64) · bun 1.4.0 · node v26.7.0
• vitest 3.2.4 (workspace-pinned) · Biome lint clean
• Branch fix/claude-memory-customid-collision — all gates re-run fresh at commit 049a50ee0ac6

[phant0um]

I checked this PR and #1676, which both address #1547.

Merged onto main (cfa6c7c), src/claude-memory.test.ts passes 32 of 32. The four pathToCustomId tests fail against the old claude-memory.ts, so they catch the bug.

Keeping the legacy id for /memories/file.txt protects the common case. Other paths now get a new id with no fallback. A file that was saved before this change, such as /memories/projects/foo.md or /memories/my_notes.md, is looked up under memories_projects_foo_md_<digest>, so view reports that it does not exist. An edit then creates a second document instead of updating the first.

A possible fix: when the lookup under the new id finds nothing, retry with the plain flattened id and accept the result only if metadata.file_path matches exactly. #1676 already does this for reads.

[MaheshtheDev]

🤖 AI-assisted triage, reviewed by @MaheshtheDev.

Thanks! #1676 fixes #1547 with legacy cleanup, so we're going with that one. Closing.