Description

When a user provides facts in the first turn (e.g. "my project uses tokio"), the agent saves them via memory_save but then recalls them in subsequent turns using search_code (code index search) rather than memory_search.

Reproduction

Config: .local/config/testing.toml (code index enabled, enabled = true in [index])

Turn 1: My project is called Zephyr and it uses Rust with the tokio async runtime. The main challenge is memory management.
Turn 2: What is the main challenge in my project?
Turn 3: What runtime does my project use?

Observed: Agent calls search_code("memory management") and search_code("tokio") to answer turns 2 and 3. Both calls use grep fallback with score 0.45. Correct answers are returned but via wrong tool.

Expected: Agent should call memory_search to recall the facts saved in turn 1, not search_code.

Tool call trace (from audit log)

memory_save  — turn 1 (correct)
search_code  — turn 2 (wrong; should be memory_search)
search_code  — turn 3 (wrong; should be memory_search)

Impact

• Unnecessary code index I/O for personal/project context facts
• Cross-session recall may fail if memory_save is done but memory_search is never invoked to confirm
• Tool filter (top_k=5) may be deprioritizing memory_search when search_code is in always_on list

Possible cause

Tool filter always_on list contains memory_search but also contains read and edit. Dynamic tool scoring may rank search_code higher for queries containing technical terms ("memory", "runtime", "tokio") because they appear as code symbols in the workspace index. The [agent.tool_filter] top_k=5 scoring likely favours code search tools over memory search for user questions that contain code-related vocabulary.

Version

HEAD: d196337, testing.toml CI-323 config