search_code rejects paths containing & (ampersand)

[aakashbadiani]

Summary

search_code (and detect_changes) reject any project whose root_path contains an ampersand (&). The validator emits:

• project path contains invalid characters
• path or file_pattern contains invalid characters

Graph-based tools (search_graph, get_code_snippet, index_status, query_graph, trace_call_path, index_repository) accept the same paths without complaint, so the restriction is specific to the grep-backed tools.

Environment

• Binary: codebase-memory-mcp.exe v0.5.7 (Windows, pure-C build from this repo)
• Host shell invoking grep: cmd.exe (Windows)

Repro

1. Index any repo whose absolute path contains &, e.g. C:\Users\me\OneDrive\300. Work\0009_A_R&D - BOM Bastic\_src_BOM_Bastic. Indexing succeeds.
2. Call search_code with project = that project name (or file_pattern containing &).
3. Observe error: path or file_pattern contains invalid characters.

Why the blacklist is overly strict

Strings in the binary reveal grep is invoked via a format like:

grep -rn %s --include='%s' -f '%s' '%s' 2>/dev/null

The path and file_pattern are already enclosed in single quotes. Inside single quotes, & is a literal character on both POSIX shells and Windows cmd.exe (cmd.exe doesn't treat ' as a quote character at all, but since & isn't being interpreted as a command separator mid-token either way when the command is parsed through /bin/sh -c via popen, there's no injection risk from & alone).

So blacklisting & blocks a safe, extremely common character (Windows "Program Files & ...", OneDrive user folders like R&D, etc.) without any corresponding security benefit.

Suggested fix

Pick one:

1. Drop & from the path/file_pattern blacklist. The existing single-quoting already neutralizes it.
2. Escape rather than reject: replace ' in the input with '\'' (POSIX) and pass through, so any metacharacter is safe.
3. Switch from popen+shell to execvp/CreateProcess directly, eliminating shell metacharacter concerns entirely.

Workaround for users

Create a directory junction at a path without &:

mklink /J C:\cbmm\myproject "C:\path\with\R&D\myproject"

Then index C:\cbmm\myproject instead.

Notes

• list_projects shows root_path with & preserved, confirming storage handles & fine -- only the grep-tool validator rejects it.

[raphaelbahat]

I have the same issue.