Greptile Summary

This PR fixes the tool name mismatch between Active Memory's recall sub-agent and the memory-lancedb backend by switching toolsAllow and the recall prompt from the legacy memory_search/memory_get pair to memory_recall. The debug transcript parser is carefully updated to stay compatible with old traces.

• The toolsAllow is now hardcoded to [\"memory_recall\"], which will silently break recall for any user whose memory slot is backed by memory-core (the other bundled backend), since memory-core exposes memory_search and memory_get and neither is in the new allowlist.

Confidence Score: 3/5

Not safe to merge as-is: fixes LanceDB recall but introduces a regression for memory-core users whose recall will silently stop working.

One P1 regression — hardcoding toolsAllow to ["memory_recall"] blocks the memory-core backend tools — prevents this from scoring higher than 3.

extensions/active-memory/index.ts — specifically the toolsAllow change at line 1692 and the prompt at lines 792–793.

This is a comment left during a code review.
Path: extensions/active-memory/index.ts
Line: 1692

Comment:
**`memory-core` backend recall will silently fail after this change**

The `toolsAllow` list is hardcoded to `["memory_recall"]`, but `memory-core` (a supported bundled backend) exposes `memory_search` and `memory_get` — neither of which is now in the allowlist. Any user whose memory slot is backed by `memory-core` rather than `memory-lancedb` will have the sub-agent blocked from calling either legacy tool, causing recall to silently produce no results.

The prompt on line 792 also now only instructs the model to call `memory_recall`, compounding the problem for `memory-core` users.

Consider expanding the allowlist to cover both contracts:
```ts
toolsAllow: ["memory_recall", "memory_search", "memory_get"],
```
and updating the prompt to either dynamically reflect the active backend or mention both tool families.

How can I resolve this? If you propose a fix, please make it concise.

---

This is a comment left during a code review.
Path: extensions/qa-lab/src/providers/mock-openai/server.ts
Line: 1475-1505

Comment:
**Dead code left in the `memory_recall` handler**

Now that the new `memoryText` branch (lines 1455–1474) returns early whenever `toolJson.text` is a string, the `memorySnippet` fallback on line 1495 repeats `typeof toolJson?.text === "string"` — a condition that can never be true here. The entire block from `const results = ...` through the `memorySnippet` assignment is unreachable for the `memory_recall` response shape. If backward compat with the old `{ results: [...] }` shape isn't intentional for this scenario, this dead code can be removed to avoid confusion.

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix(active-memory): use bundled recall t..." | Re-trigger Greptile}

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Keep open. This PR is protected by cleanup policy because the author is a MEMBER and the PR has the maintainer label. It is also still a live implementation candidate: current main still wires Active Memory to memory_search/memory_get only, while bundled memory-lancedb exposes memory_recall for recall.

Best possible solution:

Keep this PR open for explicit maintainer review. If the approach is accepted, land this PR or an equivalent patch that lets Active Memory use both bundled memory contracts, updates the docs/tests/QA mock, and records or resolves the intended privacy scope for memory-lancedb recall. Close the linked bug only after the implementation merges.

What I checked:

• Protected maintainer PR: Provided GitHub context shows authorAssociation is MEMBER and labels include maintainer. Conservative cleanup policy requires explicit maintainer judgment for this PR.
• Active Memory prompt still uses legacy tools on main: buildRecallPrompt still tells the hidden recall agent to use only memory_search and memory_get, so the PR's intended behavior is not already implemented on main. (extensions/active-memory/index.ts:851, dd643c82b55e)
• Active Memory allowlist still excludes memory_recall on main: runRecallSubagent still passes toolsAllow: ["memory_search", "memory_get"], which blocks memory-lancedb's recall tool. (extensions/active-memory/index.ts:2075, dd643c82b55e)
• memory-lancedb exposes memory_recall: The bundled memory-lancedb plugin registers memory_recall as its recall tool, and its docs list memory_recall, memory_store, and memory_forget as LanceDB memory tools. (extensions/memory-lancedb/index.ts:597, dd643c82b55e)
• memory-core still exposes the legacy contract: The bundled memory-core plugin registers memory_search and memory_get, supporting the PR discussion's updated approach of allowing both bundled tool families rather than switching exclusively to memory_recall. (extensions/memory-core/index.ts:52, dd643c82b55e)
• Docs and tests still encode the old Active Memory contract: Current docs and tests still describe or assert Active Memory's memory_search/memory_get-only behavior, which the PR updates alongside the implementation. Public docs: docs/concepts/active-memory.md. (docs/concepts/active-memory.md:83, dd643c82b55e)

Remaining risk / open question:

• Closing would violate the protected maintainer-item rule because the PR author is a MEMBER and the PR has the maintainer label.
• Current main still has the Active Memory versus memory-lancedb tool-name mismatch, so this PR is not obsolete cleanup work.
• Before merge, maintainers should explicitly resolve or accept the privacy/product scope of preferring memory_recall while memory-lancedb recall appears broad/global in the inspected current implementation.

Codex review notes: model gpt-5.5, reasoning high; reviewed against dd643c82b55e.

🔒 Aisle Security Analysis

We found 1 potential security issue(s) in this PR:

toolsAllow: ["memory_recall", "memory_search", "memory_get"],

​// in memory_recall execute
const requested = typeof limit === "number" ? limit : 5;
const safeLimit = Math.max(1, Math.min(requested, 10)); // choose a small cap
const results = await db.search(vector, safeLimit, 0.1);

Analyzed PR: #73584 at commit c997346

_{Last updated on: 2026-04-28T14:03:30Z}