memory_update rejects agent-scoped memories as outside accessible scopes

[xielk]

Plugin Version

1.1.0-beta.8

OpenClaw Version

OpenClaw 2026.3.12 (6472949)

Bug Description

memory_update can fail for memories stored in dynamic agent scopes like agent:main with the error Memory <id> is outside accessible scopes, even though the same memory can be successfully stored, recalled, and deleted.

I reproduced this locally during validation of memory-lancedb-pro on OpenClaw 2026.3.12. The issue appeared specifically when updating an agent-scoped memory that had just been created and recalled successfully.

I fixed it locally by:

• adding an optional scope parameter to memory_update
• narrowing scopeFilter using that explicit scope after access validation
• normalizing scope strings inside store.update() before comparison

After the fix, memory_update succeeded and the updated content was retrievable correctly.

Expected Behavior

memory_update should work for agent-scoped memories such as agent:main just like memory_store, memory_recall, and memory_forget, without incorrectly rejecting them as outside accessible scopes.

Steps to Reproduce

1. Store a memory in agent:main
2. Recall it successfully
3. Call memory_update on that memory
4. Observe the error: Memory <id> is outside accessible scopes

In my local validation, the same memory could still be stored, recalled, and forgotten successfully.

Error Logs / Screenshots

Observed error:

`Memory <id> is outside accessible scopes`

Environment details:
- Plugin version: 1.1.0-beta.8
- OpenClaw version: 2026.3.12 (6472949)
- Scope involved: `agent:main`
- Verified local fix: yes

Embedding Provider

None

OS / Platform

macOS 15 / Darwin arm64

[AliceLJY]

Hi @xielk, thanks for the detailed report and for digging into the fix!

Confirmed — memory_update doesn't handle dynamic agent scopes (like agent:main) consistently with memory_store / memory_recall / memory_forget. This is a valid bug.

Your fix direction (explicit scope param + scope normalization in store.update()) makes sense. We've noted this and will address it in an upcoming patch.

If you'd like to contribute a PR in the meantime, feel free — but no pressure, we'll get to it either way.

[i0ivi0i]

Reproduction confirmation from Windows / OpenClaw 2026.3.13 / memory-lancedb-pro 1.1.0-beta.9

I reproduced this on a live OpenClaw setup and can confirm the bug still exists on memory-lancedb-pro 1.1.0-beta.9.

Environment

• OpenClaw: 2026.3.13-1
• memory-lancedb-pro: 1.1.0-beta.9
• OS: Windows 11
• Main agent model: local vLLM (gpt-5.4)
• Embedding: Jina jina-embeddings-v5-text-small
• Reranker: Jina jina-reranker-v3
• Memory scope in use: agent:main

Current config characteristics

• plugins.slots.memory = memory-lancedb-pro
• enableManagementTools = true
• sessionStrategy = memoryReflection
• explicit scopes were configured:

"scopes": {
  "default": "agent:main",
  "definitions": {
    "global": { "description": "Shared knowledge across all agents" },
    "agent:main": { "description": "Private memory scope for main agent" }
  },
  "agentAccess": {
    "main": ["global", "agent:main"]
  }
}

Reproduction steps

1. Store a memory via memory_store without manually forcing another scope.
2. Confirm it is stored in agent:main.
3. Recall succeeds via memory_recall.
4. List/stats also succeed via memory_list / memory_stats.
5. Try memory_update(memoryId=..., text=...).
6. Try memory_forget(memoryId=...).

Actual result

Both management operations fail with the same error:

Memory <id> is outside accessible scopes

Important detail

This still fails even after explicitly adding agent:main to both scopes.definitions and scopes.agentAccess, then restarting the gateway.

So this does not appear to be just a missing config problem. It looks like a code-path inconsistency between:

• store / recall / list / stats
• update / forget by memoryId

What I verified

• memory_store ✅
• memory_recall ✅
• memory_list ✅
• memory_stats ✅
• memory_update ❌ outside accessible scopes
• memory_forget(memoryId=...) ❌ outside accessible scopes

This strongly suggests the agent-scoped memory is being written and read correctly, but the exact-ID management path is resolving or validating scope differently.

If useful, I can also share the exact temporary test entries and the config fragment used during reproduction.

[AliceLJY]

@i0ivi0i 感谢 Windows 端的复现确认。

我们查了源码，确认是插件侧的 bug。根因是 memory_update 的 agentId 解析逻辑和 memory_store 不一致：

• memory_store 用定义时的 runtimeContext.agentId（稳定）
• memory_update 会从执行时的 runtimeCtx 重新解析，可能拿到不同的 agentId，导致 scope 不匹配

PR #270 做了部分修复但不彻底。memory_forget、memory_stats、memory_list 也有同样的不一致。

修复方向：让所有工具统一用定义时的 agentId，和 memory_store 对齐。我们会提 PR 修复。

[AliceLJY]

修复 PR 已提交：#309

感谢 @xielk 的初始报告和详细分析，感谢 @i0ivi0i 在 Windows 端的独立复现确认，帮助我们确认了这是一个跨平台的通用问题。