hermes - 💡(How to fix) Fix [Bug]: Supermemory default/My Space config can create a literal `default` container

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Root Cause

Users intending to use one global Supermemory bucket can silently split memory across multiple containers:

  • real default/My Space, internally surfaced by Supermemory as sm_project_default
  • accidental literal tags such as default, __default__, or sanitized variants

That makes recall appear incomplete and forces manual cleanup/migration later.

Code Example

{
  "container_tag": "__default__",
  "auto_recall": true,
  "auto_capture": true,
  "max_recall_results": 8,
  "profile_frequency": 25,
  "capture_mode": "all",
  "search_mode": "hybrid"
}

---

<default/My Space>: 63 documents
literal `default`: 12 documents
literal `__default__`: 0 documents

---

_DEFAULT_CONTAINER_SENTINELS = {"", "__default__", "default", "my_space", "my space", "none", "null"}

---

Active. Container: My Space (Supermemory default).
RAW_BUFFERClick to expand / collapse

Bug description

When Hermes is configured to use Supermemory's default space, the provider can treat config values such as default / __default__ as literal Supermemory container tags instead of omitting the container tag.

Supermemory's default UI space, shown as My Space, is reached by sending no container_tag / container_tags filter. Sending a string like default creates or targets a separate tagged container graph.

Why this matters

Users intending to use one global Supermemory bucket can silently split memory across multiple containers:

  • real default/My Space, internally surfaced by Supermemory as sm_project_default
  • accidental literal tags such as default, __default__, or sanitized variants

That makes recall appear incomplete and forces manual cleanup/migration later.

Observed example

On a v0.14.0 install using the Supermemory provider, the config contained:

{
  "container_tag": "__default__",
  "auto_recall": true,
  "auto_capture": true,
  "max_recall_results": 8,
  "profile_frequency": 25,
  "capture_mode": "all",
  "search_mode": "hybrid"
}

After recent updates/local testing, Supermemory contained:

<default/My Space>: 63 documents
literal `default`: 12 documents
literal `__default__`: 0 documents

The 12 default documents had to be copied into the real default/My Space container and the default container tag deleted.

Expected behavior

Hermes should have a safe way to express "use Supermemory's default/My Space" in config, and the provider should omit container parameters for that mode.

Suggested sentinel handling:

_DEFAULT_CONTAINER_SENTINELS = {"", "__default__", "default", "my_space", "my space", "none", "null"}

For those values, resolve the active container to None and omit these fields:

  • container_tags on document add / conversation ingest
  • container_tag on search where possible
  • containerTags in raw ingest payloads

The system prompt/tool display can still show something user-friendly like:

Active. Container: My Space (Supermemory default).

Suggested tests

Add regression coverage in tests/plugins/memory/test_supermemory_provider.py for:

  1. container_tag: "__default__" resolves to provider _container_tag is None.
  2. prompt labels the default as My Space (Supermemory default).
  3. documents.add(...) omits container_tags in default mode.
  4. search.memories(...) omits explicit container_tag in default mode where the SDK allows it.
  5. conversation ingest omits containerTags in default mode.
  6. multi-container allowed list does not include None.

Notes

This is not just cosmetic. Supermemory treats container tags as graph boundaries. A literal default tag is a different graph from the default/My Space graph.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Hermes should have a safe way to express "use Supermemory's default/My Space" in config, and the provider should omit container parameters for that mode.

Suggested sentinel handling:

_DEFAULT_CONTAINER_SENTINELS = {"", "__default__", "default", "my_space", "my space", "none", "null"}

For those values, resolve the active container to None and omit these fields:

  • container_tags on document add / conversation ingest
  • container_tag on search where possible
  • containerTags in raw ingest payloads

The system prompt/tool display can still show something user-friendly like:

Active. Container: My Space (Supermemory default).

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

hermes - 💡(How to fix) Fix [Bug]: Supermemory default/My Space config can create a literal `default` container