Repository navigation
list_projects hangs indefinitely with 2 indexed projects (v0.9.0, macOS arm64, cli — single-project queries unaffected) #1195
Description
Environment
- v0.9.0, darwin/arm64 (standard, non-UI variant), installed via
install.sh - macOS on Apple silicon, 16 GB RAM
- Invoked through
clionly — 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_projects0.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 msSo 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_projectseager 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_projectsdeadlock, but Windows-specific (gitvia_popenhandle inheritance) and via the web UI. This is macOS arm64 viacli, 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.
Activity
DeusData commentedon Jul 22, 2026
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-rcdiscovery 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 commentedon Jul 28, 2026
Reproduced on v0.9.0 / darwin-arm64 / macOS 25.5.0, CLI only — MCP server never started, no watcher, no UI,
auto_indexandauto_watchbothfalse.The "exactly two projects" framing does not hold on my machine. The hang is state-dependent, not count-dependent. Observed sequence, each
list_projectsrun redirected to a fresh file:delete_projectcalls)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:
SIGKILL— I never saw the uninterruptibleUEstate reported elsewhere.codebase-memory-mcpprocesses between runs. All*.db-walfiles 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
noclobberset,> out.jsonfails 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 commentedon Jul 28, 2026
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.
DeusData commentedon Aug 14, 2026
@frankliu7 — the discriminator you built into the report is what kept this from being written off as a corrupt cache: both databases open and query fine in isolation, only the call that enumerates both hangs, and at 0.0% CPU so it is blocked rather than spinning.
@xantorres then disproved the "exactly two projects" framing with a state-dependent table, and warned everyone about the
noclobberredirection trap that had made his own first measurement read as a pass — a correction very few people would have gone back and published.Where we honestly stand:
list_projectsscans every cache database and opens each one to read its project identity, unlike the single-project path that stays healthy throughout, but reading the code has not yet identified which open state wedges. Nothing is waiting on either of you. Tonight's v0.10.5 targets the issues that make cbm impossible to operate, and a core tool that hangs until it is killed is one of them.DeusData commentedon Sep 26, 2026
Thank you, @frankliu7 and @xantorres! The state-dependent table and the
noclobberwarning were especially useful. On current main, where CLI commands go through the shared daemon, we couldn't reproduce a hang in 20 runs, including right after rapid deletes. Could either of you check v0.11.0? If it wedges, asample <pid>of the stuck process would pin down the open state.xantorres commentedon Sep 26, 2026
Thanks for the follow-up. I've since stopped using codebase-memory-mcp, so I can't retest on v0.11.0. Fine to close from my side if @frankliu7 can't reproduce either.
github-actions commentedon Sep 27, 2026
Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:
codebase-memory-mcp --versionyou're onOnce that's here we'll pick it straight back up. Heads-up: issues left
awaiting-reporterare automatically closed after a few weeks of silence, but a comment reopens the door anytime.DeusData commentedon Oct 19, 2026
Thank you both for the careful state-dependent measurements, and @xantorres for letting us know you cannot retest. No further work is expected from you. @frankliu7, if you still use cbm, confirmation on v0.11.0 or newer remains helpful; the earlier successful runs do not by themselves prove the intermittent hang resolved.