search_code returns empty on Windows: server shells out to hardcoded /bin/bash + GNU grep #422

Summary

On Windows, search_code always returns 0 results (total_grep_matches: 0, raw_match_count: 0) for every query — even patterns that definitely exist in the indexed project. The graph-backed tools (search_graph, query_graph, get_architecture, index_status, list_projects, …) all work correctly, so the index itself is fine — only the text-search path is broken. The failure is silent: an empty result is indistinguishable from "no matches."

Environment

• codebase-memory-mcp 0.6.1 (npm global, Windows x64 binary bin/codebase-memory-mcp.exe)
• OS: Windows 10 Pro (19045)
• Launched as a stdio MCP server by a Windows GUI host (Claude Code), inheriting the host process environment.

Reproduction

1. index_repository on a Windows repo — succeeds; index_status reports nodes/edges ready.
2. Call search_code with any pattern known to exist (e.g. class, or a unique identifier in the repo).
3. Every call returns {"files":[],"total_grep_matches":0,"raw_match_count":0, ...}.
4. search_graph / query_graph on the same project return correct results — confirming the index is good and only the grep/text path is broken.

Root cause

The text-search path shells out to a Unix shell pipeline with a hardcoded absolute path. Strings extracted from the shipped Windows binary show the command templates:

/bin/bash
grep -rn %s --include='%s' -f '%s' '%s' 2>/dev/null
xargs grep -n %s --include='%s' -f '%s' < '%s' 2>/dev/null

On Windows:

• /bin/bash does not exist (it's an absolute Unix path, not resolved via PATH, so no amount of PATH configuration fixes it).
• grep / xargs are not present by default.

So the spawned process fails, and because the pipeline ends in 2>/dev/null the empty output is interpreted as "no matches" rather than surfaced as an error. This affects all Windows users.

Impact

• search_code is entirely non-functional on Windows.
• The empty-vs-unavailable ambiguity means agents/users silently get wrong (empty) answers and may conclude code doesn't exist when it does.

Suggested fixes (any one)

1. In-process native search (preferred). The project ships as a single static Rust binary ("zero dependencies"); using the grep/grep-searcher + ignore/globset crates (ripgrep's libraries) in-process removes the external bash/grep/xargs dependency entirely, is cross-platform, and is faster.
2. Invoke ripgrep directly (no shell). Spawn rg with --glob (instead of grep --include + xargs under bash); avoids the shell and the /bin/bash assumption. Bundle rg or document it as a dependency.
3. At minimum, fail loudly. Detect when the search backend can't run and return an explicit error to the client instead of an empty result set.

Current workaround for Windows users

Run the Linux build of the server inside WSL (e.g. configure the MCP command as wsl -e codebase-memory-mcp), where /bin/bash, grep, and xargs exist natively; index via /mnt/c/... paths. The Windows-native binary's search_code cannot work without a Unix shell environment.