search_code returns 0 matches when the indexed repo path contains a space (macOS)

[doug306]

Summary

search_code returns total_grep_matches: 0 for every pattern when the repository was indexed from a path that contains a space. The graph tools (search_graph, get_code_snippet, query_graph, get_architecture) work correctly on the same index — only search_code is affected. Re-indexing the identical tree from a path without a space makes search_code return correct results.

This looks like a sibling of #272 (search_code rejects paths containing &): the live grep / path handling doesn't appear to be quote/escape-safe for whitespace either, but here it fails silently (empty result, no error).

Environment

• Version: codebase-memory-mcp 0.8.1 (release binary)
• Platform: macOS x86_64 (Darwin)

Repro

# 1) Index a repo whose path contains a space:
codebase-memory-mcp cli index_repository '{"repo_path":"/Users/me/Dev Projects/myrepo"}'
# → {"status":"indexed","nodes":<N>,"edges":<M>, ...}   (indexing itself works fine)

# 2) search_code finds nothing — even for guaranteed-present strings:
codebase-memory-mcp cli search_code '{"project":"<slug>","pattern":"export function"}'
# → {"results":[],"raw_matches":[],"total_grep_matches":0,"total_results":0, ...}

# 3) But the graph tools work on the SAME index:
codebase-memory-mcp cli search_graph '{"project":"<slug>","name_pattern":"someFunc"}'
# → correct results (qualified_name, in_degree, file_path, ...)

# 4) Re-index the SAME tree via a no-space path (symlink) → search_code works:
ln -s "/Users/me/Dev Projects/myrepo" /tmp/myrepo
codebase-memory-mcp cli index_repository '{"repo_path":"/tmp/myrepo"}'
codebase-memory-mcp cli search_code '{"project":"<slug2>","pattern":"export function"}'
# → total_grep_matches: 100+   ✅

Reproduces identically via the cli interface and via MCP tools/call.

Impact

On macOS, user code commonly lives under paths with spaces (e.g. ~/Dev Projects/…, iCloud ~/Library/Mobile Documents/…). For those repos search_code is silently non-functional — it returns an empty result rather than erroring, which is easy to misread as a genuine "no matches."

Workaround

Index the repo via a symlink whose path contains no spaces.

[Kiog-Aser]

This looks like it's failing in the path normalization logic before it even hits the index. Since search_code is failing silently while the graph tools work, it’s likely the grep-based fallback doesn’t have the same quote-safety that the graph engine does.

Your symlink workaround is the cleanest fix for now. I've been wrestling with similar macOS path edge cases while building LockIn (system-level host file stuff) and spaces in ~/Library are always the pain point.

[DeusData]

Thanks for the clean repro. I’ve triaged this under #396 as the space-in-path sibling of #272. The fix should remove shell-quoting sensitivity from search_code path handling and add a path-with-spaces regression test.

[noelsaw1]

Independently hit this today on 0.8.1 / macOS (Darwin 24.6.0) — still reproduces, 5 weeks on. Adding a minimal A/B repro since you mentioned wanting a path-with-spaces regression test, plus one triage trap that nearly made me refute the diagnosis.

Minimal repro — two repos, byte-identical, differing only by a space

mkdir -p "/tmp/probe/nospace" "/tmp/probe/with space"
for d in "nospace" "with space"; do
  printf 'function uniqueProbeToken() { return 42; }\n' > "/tmp/probe/$d/probe.js"
  git -C "/tmp/probe/$d" init -q && git -C "/tmp/probe/$d" add -A \
    && git -C "/tmp/probe/$d" -c user.email=a@b -c user.name=t commit -qm init
done
# md5 of both probe.js: bec03132b20dfc1ae96e48f37de4cd89 (identical)

Index both (mode: fast) — both report nodes: 4, edges: 3, so the indexes are equivalent. Then search_code with pattern: "uniqueProbeToken":

repo root	total_grep_matches	files
/tmp/probe/nospace	1	["probe.js"]
/tmp/probe/with space	0	[]

Same content, same mode, same node/edge counts, same pattern — the space in the path is the only variable. Should drop straight in as a fixture.

Also confirmed on real repos

search_code returns 0 for every pattern on three existing repos under ~/Documents/GH Repos/…, while search_graph on the same indexes returns correct results (207 hits for a BM25 query, with file_path + line numbers) — matching your "graph tools fine, only search_code affected" finding. A repo at ~/Documents/rebalance-OS (no space) works normally: 500 grep matches.

Index mode is not a factor — re-indexing the same repo as moderate instead of fast still gives 0.

Triage trap worth knowing when you write the regression test

A project whose indexed root no longer exists on disk also returns total_grep_matches: 0, silently and identically.

I used one as a "no-space control" (/Users/…/wt/gh-155-…, a deleted git worktree still in list_projects), got 0, and briefly concluded the space hypothesis was wrong. It wasn't — the control was invalid. Only after checking -d on each indexed root did the pattern become clean:

root	space?	exists?	search_code
~/Documents/rebalance-OS	no	yes	works
~/Documents/GH Repos/* (×3)	yes	yes	0
~/wt/gh-155-direct-commit-signals	no	no	0 ← invalid control

So there are (at least) two independent silent-zero paths. If the fix only covers quoting, a stale-root project will still return a confident empty result that reads as "no matches." Might be worth having search_code distinguish "pattern not found" from "could not search" — the empty result is the part that costs the most time, because there's nothing to indicate the search never actually ran.