Problem
The Mem0 memory plugin lets gateway-supplied user_id (passed in kwargs at session initialization) override the configured user_id in mem0.json. For single-user installs this silently fragments Mem0's namespace across gateways.
Concrete repro:
- Configure
~/.hermes/mem0.json with "user_id": "matvey"
- Send a message via the Telegram gateway from Telegram user ID
1370472126
- In the Mem0 dashboard, observe that the Telegram-originated memory is scoped under
user_id="1370472126", while messages from the local TUI are scoped under user_id="matvey"
mem0_search from the TUI cannot find Telegram-originated facts; the namespaces are siblings, not unified
Why this matters: every gateway path with a different user_id source (Telegram numeric IDs, Discord IDs, web chat session IDs) creates its own Mem0 namespace. Searches scoped to matvey silently miss memories tagged with 1370472126. hermes doctor doesn't surface the fragmentation.
Current code: plugins/memory/mem0/__init__.py:208
self._user_id = kwargs.get("user_id") or self._config.get("user_id", "hermes-user")
The comment at L206–207 says this is intentional — "Prefer gateway-provided user_id for per-user memory scoping" — which is correct for multi-tenant deployments but counter-productive for single-user installs.
Proposed solution
Add a force_user_id boolean config option to mem0.json. Default false (preserves current behavior). When true, ignore gateway kwargs:
{
"user_id": "matvey",
"agent_id": "echo",
"rerank": true,
"force_user_id": true
}
if self._config.get("force_user_id"):
self._user_id = self._config.get("user_id", "hermes-user")
else:
self._user_id = kwargs.get("user_id") or self._config.get("user_id", "hermes-user")
Backward compat
Default to false — existing multi-user/multi-tenant setups continue to behave identically.
Documentation
plugins/memory/mem0/README.md already documents user_id, agent_id, rerank. Add force_user_id to that table.
Doctor check
hermes doctor could flag detected Mem0 namespace fragmentation (multiple user_ids in the same Mem0 account) and suggest setting force_user_id if the account is meant to be single-user.
Affected versions
Hermes 0.8.0+ (confirmed reproducing).
Working local patch
I'm running a config-first patch in production (self._user_id = self._config.get("user_id") or kwargs.get("user_id") or "hermes-user") — works fine for the single-user case but isn't what should ship. The config flag is the right shape.
Happy to send a PR if there's interest.
Problem
The Mem0 memory plugin lets gateway-supplied
user_id(passed in kwargs at session initialization) override the configureduser_idinmem0.json. For single-user installs this silently fragments Mem0's namespace across gateways.Concrete repro:
~/.hermes/mem0.jsonwith"user_id": "matvey"1370472126user_id="1370472126", while messages from the local TUI are scoped underuser_id="matvey"mem0_searchfrom the TUI cannot find Telegram-originated facts; the namespaces are siblings, not unifiedWhy this matters: every gateway path with a different
user_idsource (Telegram numeric IDs, Discord IDs, web chat session IDs) creates its own Mem0 namespace. Searches scoped tomatveysilently miss memories tagged with1370472126.hermes doctordoesn't surface the fragmentation.Current code:
plugins/memory/mem0/__init__.py:208The comment at L206–207 says this is intentional — "Prefer gateway-provided user_id for per-user memory scoping" — which is correct for multi-tenant deployments but counter-productive for single-user installs.
Proposed solution
Add a
force_user_idboolean config option tomem0.json. Default false (preserves current behavior). When true, ignore gateway kwargs:{ "user_id": "matvey", "agent_id": "echo", "rerank": true, "force_user_id": true }Backward compat
Default to
false— existing multi-user/multi-tenant setups continue to behave identically.Documentation
plugins/memory/mem0/README.mdalready documentsuser_id,agent_id,rerank. Addforce_user_idto that table.Doctor check
hermes doctorcould flag detected Mem0 namespace fragmentation (multiple user_ids in the same Mem0 account) and suggest settingforce_user_idif the account is meant to be single-user.Affected versions
Hermes 0.8.0+ (confirmed reproducing).
Working local patch
I'm running a config-first patch in production (
self._user_id = self._config.get("user_id") or kwargs.get("user_id") or "hermes-user") — works fine for the single-user case but isn't what should ship. The config flag is the right shape.Happy to send a PR if there's interest.