Summary

• Problem: Active Memory lightweight embedded recall runs can allowlist Memory Core tools before those runtime plugin tools are materialized, collapsing the callable tool set.
• Why it matters: memory_search and memory_get should remain callable when Memory Core is installed and Active Memory scopes the embedded run to memory tools.
• What changed: runtime toolsAllow now contributes to generic plugin tool materialization, and Active Memory opts into gateway subagent binding for the embedded recall run.
• What did NOT change (scope boundary): no plugin-specific tool IDs were hardcoded in core behavior, and no public SDK surface or memory storage behavior changed.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes active-memory + memory-core dont compose: lightweight sub-agent bootstrap excludes memory-kind plugin tools, allowlist resolves to empty, placeholder turn lands in transcript #74572
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: embedded runs applied the final runtime tool filter after creating the tool set, but the runtime toolsAllow was not also used to materialize matching plugin tools before that final filter.
• Missing detection / guardrail: no focused test covered a lightweight embedded run that allowlists plugin-provided memory tools.
• Contributing context (if known): Active Memory uses a narrow memory tool allowlist for recall runs while Memory Core registers memory_search and memory_get as plugin tools.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/active-memory/index.test.ts, src/agents/pi-embedded-runner/run/attempt.test.ts, src/agents/pi-tools.create-openclaw-coding-tools.test.ts
• Scenario the test should lock in: Active Memory recall runs pass gateway subagent binding, embedded attempt context carries runtime allowlists, and runtime allowlists contribute to plugin tool materialization.
• Why this is the smallest reliable guardrail: it tests the generic tool composition seams without requiring a full gateway session.
• Existing test that already covers this (if any): src/plugins/tools.optional.test.ts covers optional plugin tools and gateway-bindable registry behavior.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

Active Memory recall runs can now call Memory Core plugin tools when Memory Core is installed and those tools are explicitly allowlisted for the embedded run.

Diagram (if applicable)

Before:
Active Memory recall -> toolsAllow(memory_*) -> plugin tools not materialized -> final filter can leave no callable memory tools

After:
Active Memory recall -> toolsAllow(memory_*) -> materialize matching plugin tools -> final filter keeps callable Memory Core tools

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) Yes
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: embedded runs can materialize only plugin tools already included in the explicit runtime allowlist and gateway-bindable registry; the final allowlist filter still applies.

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node.js v24.14.0, pnpm 10.33.0
• Model/provider: N/A
• Integration/channel (if any): Active Memory + Memory Core
• Relevant config (redacted): N/A

Steps

1. Install Memory Core and Active Memory.
2. Trigger an Active Memory embedded recall run with bootstrapContextMode: "lightweight" and toolsAllow: ["memory_recall", "memory_search", "memory_get"].
3. Verify Memory Core plugin tools are materialized before the final embedded tool allowlist filter.

Expected

• memory_search and memory_get remain callable when registered by Memory Core and explicitly allowlisted by the embedded run.

Actual

• Before this change, the runtime allowlist could resolve to no callable tools because matching plugin tools were not materialized before final filtering.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • pnpm test extensions/active-memory/index.test.ts src/agents/pi-embedded-runner/run/attempt.test.ts src/plugins/tools.optional.test.ts src/agents/pi-tools.create-openclaw-coding-tools.test.ts
  • pnpm exec oxfmt --check --threads=1 extensions/active-memory/index.ts extensions/active-memory/index.test.ts src/agents/pi-embedded-runner/run/attempt.tool-run-context.ts src/agents/pi-embedded-runner/run/attempt.test.ts src/agents/pi-tools.ts src/agents/pi-tools.create-openclaw-coding-tools.test.ts src/agents/test-helpers/fast-openclaw-tools.ts CHANGELOG.md
  • git diff --check
  • codex review --base origin/main
• Edge cases checked:
  • runtime allowlist propagation when toolsAllow is present
  • generic plugin tool materialization without hardcoded memory plugin IDs
  • Active Memory preserves lightweight bootstrap and narrow memory tool allowlist
• What you did not verify:
  • pnpm check:changed currently fails in extension test typecheck on a pre-existing duplicate-property error in extensions/memory-wiki/src/claim-health.test.ts that is present on origin/main.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: broader plugin tool materialization than intended for embedded runs.
  • Mitigation: only explicit runtime allowlist entries are added to the existing plugin tool allowlist composition, and the final tool filter still applies.