Summary

memory_search and memory_get are hardcoded in the SUBAGENT_TOOL_DENY_ALWAYS constant in the sub-agent tool policy pipeline. This means no sub-agent session can use memory tools, regardless of agent-level or global configuration.

For multi-agent setups that rely on shared memory (lessons, decisions, context), this effectively blocks memory adoption for any agent work done via sessions_spawn.

Environment

• OpenClaw: 2026.3.24 (cff6dc9)
• OS: Darwin 24.5.0 (arm64)
• Memory backend: default (sqlite + gemini embeddings)
• Memory status: fully indexed, vector ready, embeddings ready
• Config: memorySearch.enabled: true, extraPaths configured per agent

Root cause

In pi-embedded-BaSvmUpW.js (line ~114190):

const SUBAGENT_TOOL_DENY_ALWAYS = [
    "gateway",
    "agents_list",
    "whatsapp_login",
    "session_status",
    "cron",
    "memory_search",   // ← should not be here
    "memory_get",       // ← should not be here
    "sessions_send"
];

This deny list is applied to ALL sub-agent sessions regardless of depth or config.

Workaround

Adding explicit tool names to tools.subagents.tools.alsoAllow overrides the hardcoded deny (the resolveSubagentToolPolicy function filters baseDeny by explicitAllow):

{
  "tools": {
    "subagents": {
      "tools": {
        "alsoAllow": ["memory_search", "memory_get"]
      }
    }
  }
}

Note: group:memory does NOT work here — the group shorthand is not expanded in resolveSubagentToolPolicy. Only explicit tool names work.

What does NOT work

• agents.list[].tools.alsoAllow: ["group:memory"] — wrong scope (per-agent, not subagent policy)
• agents.list[].tools.alsoAllow: ["memory_search"] — same issue
• tools.subagents.tools.alsoAllow: ["group:memory"] — group not expanded

Why memory tools should not be in DENY_ALWAYS

1. Read-only tools: memory_search and memory_get are read-only with no side effects. They cannot modify state, send messages, or affect external systems.
2. Essential for multi-agent setups: Any serious multi-agent deployment with shared knowledge relies on memory tools for context retrieval.
3. Other read-only tools are allowed: read, web_search, web_fetch, pdf, image are all available to sub-agents by default. Memory tools serve the same purpose (information retrieval).
4. Config says enabled: memorySearch.enabled: true and full index readiness suggest the intent is for memory to be available. The hardcoded deny silently contradicts this.

Expected behavior

memory_search and memory_get should NOT be in SUBAGENT_TOOL_DENY_ALWAYS. They should follow the normal tool policy pipeline (allow/deny from agent config and tools.subagents.tools).

Steps to reproduce

1. Configure a multi-agent setup with memorySearch.enabled: true
2. Spawn a sub-agent via sessions_spawn with agentId pointing to an agent with memory indexed
3. Ask the sub-agent to use memory_search
4. Observe: tool is not available in the sub-agent runtime

Additional context

• openclaw memory search --agent <id> works correctly from CLI
• Direct agent sessions (Telegram, cron) have memory tools available
• The fix in 2026.3.22 (fix(memory-core): register memory tools independently to prevent coupled failure #50198, "register memory_search and memory_get independently") does not help because the tools are denied at the policy level, not the registration level
• Tested with 5+ agents across 20+ sessions — zero memory_search calls in any sub-agent session