list_projects hangs indefinitely with 2 indexed projects (v0.9.0, macOS arm64, cli — single-project queries unaffected)

[frankliu7]

Environment

• v0.9.0, darwin/arm64 (standard, non-UI variant), installed via install.sh
• macOS on Apple silicon, 16 GB RAM
• Invoked through cli only — the MCP server was never started, no watcher, no UI
• Cache: ~/.cache/codebase-memory-mcp, 266 MB total

Summary

With exactly two indexed projects, list_projects blocks indefinitely and never returns. It has to be killed. Every other tool on the same cache keeps working normally, so this is specific to multi-project enumeration — not a corrupt cache and not a stuck database.

Repro

# 1. Index project A (private Python monorepo)
$ cbm cli index_repository --repo-path /path/to/A --mode full
{... "nodes":81527,"edges":301976,"status":"indexed"}          # 7.0 s

# 2. With ONE project in the cache, list_projects is instant
$ cbm cli list_projects
{"projects":[{"name":"...","nodes":81527,"edges":301976,"size_bytes":238682112}]}   # < 1 s

# 3. Index project B (a second, smaller repo)
$ cbm cli index_repository --repo-path /path/to/B --mode full
{... "nodes":14478,"edges":50848,"status":"indexed"}           # 1.3 s

# 4. With TWO projects, list_projects never returns
$ cbm cli list_projects
level=info msg=mem.init budget_mb=4096 total_ram_mb=16384
# ...hangs. Killed at 30 s, 180 s, and 335 s in three separate runs.

Reproduced 3/3 on a clean process table (all prior codebase-memory-mcp processes killed, no MCP server running).

Process state while hung

$ ps -eo pid,etime,%cpu,%mem,command | grep codebase-memory
 1563  05:35   0.0  0.0 codebase-memory-mcp cli list_projects
 2083  03:11   0.0  0.0 codebase-memory-mcp cli list_projects

0.0% CPU — blocked, not spinning. No log output beyond the mem.init line; ~/.cache/codebase-memory-mcp/logs/ stays empty.

Cache state (both DBs healthy)

40,501,248   <B>.db          32,768  <B>.db-shm          0  <B>.db-wal
238,682,112  <A>.db          32,768  <A>.db-shm          0  <A>.db-wal

Key discriminator — single-project access is unaffected

Immediately after killing the hung list_projects, both projects query fine:

$ cbm cli search_graph --project <A> --query "..." --limit 2     # rc=0, 44 ms
$ cbm cli search_graph --project <B> --query "..." --limit 2     # rc=0, 13 ms

So each database opens, reads and returns normally in isolation. Only the call that enumerates both hangs.

Impact

list_projects is the discovery entry point — the tool description for index_status explicitly tells callers to "Run list_projects to see indexed projects". Once a second project exists, an agent following that guidance blocks forever rather than getting an error, and there is no timeout or partial result to fall back on.

Relationship to existing issues (checked before filing; none appear to cover this)

• list_projects should paginate and avoid eager per-project details #1066 — list_projects eager per-project work: ~61.5 s with 500 projects. That is linear slowness; this is an unbounded hang with 2. Pagination as proposed there would not fix a call that never returns.
• Project remains listed but becomes unqueryable after MCP restart with stale WAL/SHM sidecars #790 — stale WAL/SHM sidecars leaving a project unqueryable after MCP restart. Here single-project queries succeed and no MCP server was ever started.
• Windows: web UI hangs — list_projects deadlocks the HTTP server (git via _popen handle inheritance) #798 — list_projects deadlock, but Windows-specific (git via _popen handle inheritance) and via the web UI. This is macOS arm64 via cli, no UI.
• list_projects/index_status report the resident set, not the indexed set: with >6 indexed projects the LRU-evicted one reports "not indexed" (v0.9.0) #1115 — LRU eviction misreporting with >6 projects; this occurs at 2.

Happy to gather anything further (sampled stack via sample, fs_usage, a CBM_CACHE_DIR-isolated two-project repro on public repos) if useful.

[DeusData]

Thanks for the strong two-project isolation and process-state evidence. I removed the incorrect Windows/parsing labels and classified this as a high-priority 0.9.1-rc discovery hang under #593. The RED case will use two healthy stores in an isolated cache and require bounded completion; single-project query health must remain intact. No further reporter action is needed right now.

[xantorres]

Reproduced on v0.9.0 / darwin-arm64 / macOS 25.5.0, CLI only — MCP server never started, no watcher, no UI, auto_index and auto_watch both false.

The "exactly two projects" framing does not hold on my machine. The hang is state-dependent, not count-dependent. Observed sequence, each list_projects run redirected to a fresh file:

Projects indexed	Result
4	OK, sub-second
1 (immediately after 5 rapid delete_project calls)	hang, killed at 120 s
1	hang, killed at 25 s
1	OK
2	hang ×8 consecutive, killed at 15 s each
1, 2, 3	OK, 0.02–0.54 s

So it hung at 1 and at 2, and was fine at 1, 2, 3, and 4. It entered a bad state, stayed there across ~10 consecutive invocations, then cleared after further index/delete operations.

Additional data points:

• Killable with SIGKILL — I never saw the uninterruptible UE state reported elsewhere.
• No lock file, no daemon process, and no live codebase-memory-mcp processes between runs. All *.db-wal files were 0 bytes.
• index_status --project <name> never hung, including during the 8-consecutive-hang window. It looks like a viable workaround.

Methodology warning for anyone else measuring this: my first attempt reported 0/6 hangs and was wrong. Under zsh with noclobber set, > out.json fails for runs 2..n and the reader silently re-reads run 1's output. Use a unique output file per run, or you will measure a hang as a pass.

[DeusData]

Thanks for the careful rerun and for correcting the shell redirection pitfall.

The new data disproves “exactly two projects” as the trigger. Current main's list_projects path is distinct from index_status: it scans every cache DB and opens each one to read its internal project identity (src/mcp/mcp.c:2081-2124), while a single-project query resolves one store. That matches the fact that index_status stayed healthy during the bad state, but static code does not yet identify which DB/open state causes the intermittent hang.

Keeping this priority/high in 0.9.1-rc with the corrected state-dependent scope. No awaiting-reporter label is appropriate; the new measurements already move the investigation forward. Thank you.