Bug: supermemory_store is not reliably roundtrip-searchable/deletable via supermemory_search / supermemory_forget(query)

[pascalkienast]

Summary

Manual supermemory_store writes are acknowledged as successful, but they are not reliably discoverable afterwards via supermemory_search, and therefore also not reliably removable via supermemory_forget(query).

This appears to be more than simple indexing delay. In my testing, the stored text exists in the underlying Supermemory document and the document is already in status: done, but the text is still not returned by supermemory_search.

Why this matters

For passive auto-recall this may be acceptable, but for explicit/manual memory operations the tool semantics become misleading:

• supermemory_store suggests “this was saved and can be recalled later”
• supermemory_search cannot reliably find that exact stored item
• supermemory_forget(query) depends on the same search path, so it also fails

This makes manual memory control unreliable.

Reproduction

Environment

• OpenClaw Supermemory plugin: @supermemory/openclaw-supermemory 2.0.2
• Repo: supermemoryai/openclaw-supermemory
• Container tag: default OpenClaw container
• Auto-recall / auto-capture enabled

Steps

1. Call:

{
  "text": "Supermemory smoke test marker — created by Pi on 2026-03-09 in Discord #ops. Unique token: SMOKE-1480601243586920520."
}

via supermemory_store

2. Observe successful response:

Stored: "Supermemory smoke test marker — created by Pi on 2026-03-09 in Discord #ops. Uni…"

3. Immediately call:

{
  "query": "SMOKE-1480601243586920520"
}

via supermemory_search

4. Result:

No relevant memories found.

5. Wait a bit and retry supermemory_search

   • still no result

6. Call supermemory_forget with the same query:

{
  "query": "SMOKE-1480601243586920520"
}

7. Result:

No matching memory found to forget.

Important observation: the data was actually stored

Using the underlying SDK / API directly, I can confirm that the unique token is present in the raw stored document:

• the document exists
• it is in status: done
• the token appears in the raw document content
• but it is still not returned by search.memories(...)

In my case, the token was appended to a large session document with:

• customId = session_agent_main_discord_channel_1478191885863354563

and the raw document content did contain:

Supermemory smoke test marker — created by Pi on 2026-03-09 in Discord #ops. Unique token: SMOKE-1480601243586920520.

Suspected root cause

From reading the plugin source:

• supermemory_store uses buildDocumentId(sessionKey) and writes with a session-level customId
• this means manual stores are effectively merged into a session document
• supermemory_search uses client.search.memories(...)
• supermemory_forget(query) also depends on search.memories(...)

So there seems to be a mismatch between:

1. store path → document/session update
2. search path → extracted memories only
3. forget-by-query path → same extracted-memory search

If the extraction layer does not promote the stored text into a memory entity, the text is effectively “stored but not roundtrip-addressable” through the plugin tools.

Expected behavior

At least one of these should be true:

Option A

Manual supermemory_store writes should become reliably retrievable via supermemory_search, and removable via supermemory_forget(query).

Option B

If manual stores are intentionally document-level only, the tool semantics / docs should make that explicit, because right now the interface implies a stronger guarantee than the implementation provides.

Possible fixes

A few possible directions:

1. Do not reuse session-level customId for manual supermemory_store

   • create a separate document / memory entity for explicit manual stores

2. Add fallback search behavior

   • if search.memories(...) returns nothing, optionally fall back to a document/hybrid search path

3. Improve supermemory_forget(query)

   • support exact content deletion / document-aware fallback when a query is clearly targeting a manual store

4. Clarify docs

   • if current behavior is intended, document that supermemory_store is not guaranteed to be exact-roundtrip searchable/deletable

Additional note

This does not seem to be simple processing lag in my case, because:

• the document had already finished processing (status: done)
• the raw content contained the token
• only the memory-search path failed to surface it