Skip to content

mem0 plugin: session-scoped memories persist across /new resets (run_id = stable sessionKey) #31253

Description

@Servo-AIpex

Bug

The openclaw-mem0 plugin maps run_id to the OpenClaw sessionKey (e.g. agent:main:telegram:direct:5263871946), which is a durable channel identifier that survives /new and /reset commands. This means:

  1. Session memories are never isolated per conversation — all auto-captured memories share the same run_id across session resets
  2. memory_list(scope=session) returns all auto-captured memories ever, not just the current conversation
  3. Session memory pool grows unbounded (168+ in my case after a few days)

Expected behavior

/new should generate a fresh run_id so that session-scoped memories are isolated to the current conversation, matching Mem0's intended semantics:

Mem0 field Intended scope Current OpenClaw mapping
user_id Human identity (persistent) cfg.userId or ctx.agentId (inconsistent)
run_id Conversation thread (ephemeral) sessionKey (durable channel ID) ❌
agent_id Agent identity (persistent) Not used

Additional bug found

Auto-capture uses ctx.agentId (e.g. "main") as user_id, but the memory tools (memory_list, memory_search, memory_store) fall back to cfg.userId (e.g. "default"). This causes tools to miss all auto-captured memories entirely. I patched this locally by adding currentAgentUserId fallback to the tools.

Proposed fix

  1. Generate a new run_id (UUID or incrementing counter) on /new//reset, pass it to the plugin instead of sessionKey
  2. Consistently use user_id for the human identity across auto-capture and tools
  3. Use agent_id for the agent name (currently unused)
  4. (Plugin-side) Fix currentAgentUserId fallback in tool handlers (I have a working patch)

Environment

  • OpenClaw 2026.2.26
  • openclaw-mem0 plugin v0.1.2 (OSS mode)
  • Qdrant vector store
  • Mem0 SDK 2.2.1

/cc @gevertex

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Fields

Priority

None yet

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions