[Feature] Per-user long-term memory isolation when multiple users share one agent (e.g. Feishu DM; integrate user: scope with auto-capture/auto-recall)

[eightHundreds]

Background

On channels such as Feishu (Lark), multiple real users may DM the same agent. We want long-term memory isolated per user, so user A’s and user B’s memories are not merged into one shared corpus.

Current behavior / problem

The plugin already supports multiple scopes (including user:<id>) and scopes.agentAccess, and tools can pass an explicit scope.

However, on autoCapture / autoRecall hook paths, the default read/write scope comes from getDefaultScope(agentId), typically agent:<agentId>. There is no automatic mapping from OpenClaw session context (channelId, conversationId, channel-specific user ids, etc.) to user:<stable-user-id>.

So when one agent id serves many users in DM, auto-captured memories all land in the same agent:* bucket, which risks cross-user bleed.

Desired behavior (feature)

When enabled via configuration:

1. Resolve a per-user scope key (e.g. user:<id>) from host context using documented, stable fields (e.g. ctx.conversationId, ctx.channelId, accountId, Feishu open_id / user_id, or whatever OpenClaw exposes per channel).
2. autoCapture writes and autoRecall / before_prompt_build retrieval should default to that scope (subject to scopes / ACL).
3. Backward compatibility: when the feature is off, keep today’s semantics (primarily agent:<id>). Policy for global and shared buckets can be discussed separately.

Possible implementation directions (for maintainers)

• Add configuration, e.g. scopes.perUserDefaultFromContext: { enabled, field, prefix: "user:" } (exact field names must align with OpenClaw channel contracts).
• Or align with an OpenClaw-level “default scope per session” so behavior is not plugin-only.

Related notes

• Built-in user: pattern and MemoryScopeManager already exist in this repo.
• Feishu envelope metadata must not be stored as memory (see e.g. [Bug] autoCapture includes Feishu metadata in stored memories #211); that is orthogonal but part of the same channel story.

Related OpenClaw upstream discussions

These track similar multi-user / per-session / channel-aware needs at the host level; linking them here so plugin work can stay aligned with (or delegate to) OpenClaw:

• [RFC] memory_search: Add user-scoped memory isolation for multi-user deployments openclaw/openclaw#3259 — RFC: user-scoped memory isolation for multi-user deployments (memory_search / memory_get scope leakage).
• [Feature]: User-based workspace and memory system with multi-channel binding support openclaw/openclaw#3827 — User-based workspace and memory system with multi-channel binding.
• [Feature]: Per-user context files for single-agent, multi-user setups openclaw/openclaw#18565 — Per-user context files for single-agent, multi-user setups (peer-scoped USER.md-style files).
• Channel-aware memory context openclaw/openclaw#7776 — Channel-aware memory context.
• Default DM sessions to per-channel scope (avoid webchat contention) openclaw/openclaw#7868 — Default DM sessions to per-channel scope (avoid webchat contention; historical PR — may be stale/closed).

Example environment

• OpenClaw + Feishu channel, multiple users DMing the same bot/agent.

[AliceLJY]

Important feature for multi-user DM scenarios. Some thoughts:

Approach

The user: scope pattern already exists in MemoryScopeManager, so the plumbing is partially there. The gap is in the auto-capture/auto-recall hooks which default to agent:<id> scope.

Suggestion

Rather than a plugin-only config, this should align with how OpenClaw exposes session context. The key question is: what stable user identifier does OpenClaw provide per channel?

• Feishu: open_id is stable per app-user pair
• Slack: workspace user_id
• Discord: user_id

A config like:

"scopes": {
  "autoScopeFromContext": {
    "enabled": true,
    "contextField": "userId",
    "prefix": "user:"
  }
}

would let the plugin resolve the scope dynamically from whatever OpenClaw passes in session context, without hardcoding channel-specific logic.

Backward compatibility

Agree — this should be opt-in with enabled: false as default. Existing setups continue using agent:<id> scope.

Cross-user bleed risk

Worth noting: even with per-user scope, global scope memories are still shared. The ACL layer (scopes.agentAccess) should be documented clearly to avoid confusion about what's isolated vs shared.

Good proposal — let's see what stable context fields OpenClaw currently exposes before finalizing the design.