17 MCP tools answer structural questions from one persistent graph
The v0.11.0 server keeps a local map of symbols and their relationships, exposed through 17 MCP tools. An agent can ask what calls a function, which tests touch it, where a route is handled, or what a changed file may affect. The answer comes from a stored SQLite graph instead of another tour through dozens of source files. That is the useful idea here: give the model a smaller, structured view, while keeping the source code available for confirmation.
Those tools cover indexing, search, call tracing, architecture summaries, change detection, code snippets, and read-only Cypher-style queries. Tree-sitter handles syntax across the project's broad language set, while a narrower Hybrid LSP layer adds type-aware resolution for named languages. There is no model inside the server. Your existing MCP client interprets the request and decides which graph tool to call.
One native binary also installs a daemon, watcher, and UI
The v0.11.0 release serves its graph UI on port 9749 from the same native install used for the local server. That install supports macOS, Linux, and Windows, keeps indexes under the user's cache directory, starts a per-account coordination daemon when a compatible session needs it, and can watch Git changes for incremental reindexing. No hosted account or model credential is required for those jobs.
Convenience comes with reach. The installer detects coding agents, writes their MCP entries, and may add instructions, skills, or lifecycle hooks where the client supports them. Codex asks users to review and trust installed hooks, and some clients receive only a limited integration because their hook contracts are weak. If desktop configuration is managed centrally, inspect the scripts and use the documented manual MCP entry instead of handing the installer every detected client.
What happened when we ran it
Our sandbox run used commit 1f9b4db on September 28, 2026, with 3 CPUs, 8 GB of RAM, Node 22, no secrets, and an unprivileged container. The checkout contained 2,246 files, about 2,523,779 lines of source, and occupied 1,375.2 MB. The detected Node project lived under ./graph-ui/.
Installing that package succeeded in 31 seconds. npm added 352 packages and used 357 MB on disk. The build completed in 17 seconds, and Vitest finished in 11 seconds with 47 passed and 0 failed. npm audit reported 0 known vulnerabilities at every severity.
Our method covered the detected Node project only. The repository also contained 23 CI workflow files, a tests directory, and no Dockerfile. These results verify the UI package at the measured commit. They do not test the native C indexer, the prebuilt release binary, indexing speed, graph accuracy, or the full source suite. Treat the clean 47-test result as UI evidence, not a blanket certificate for every path in the repository.
Open issue #1642 makes dead-code results leads, not deletion orders
In the Python example attached to issue #1642, all 50 cases shown as dead were live. Constructors, framework-invoked methods, and callbacks by reference can appear dead because the detector sees no incoming graph edge. That does not make the feature useless. It makes dead a lead for inspection rather than a deletion list.
Freshness has a separate failure mode. Issue #1429 describes nested repositories that do not reindex after a branch switch, even though status reads the live branch and commit from disk. The graph can therefore look current while returning symbols from the old tree. The documented workaround is a manual reindex using the existing project name. Anyone using nested checkouts should make that reindex part of branch-changing automation.
Issue #2399 found a 4 GiB Windows staging boundary
Open issue #2399 reports v0.11.0 completing analysis on a very large Windows repository, then failing to publish when the staging database reached exactly 4 GiB. Splitting the source into several projects worked for the reporter but fragmented some cross-project analysis. This is a narrow case, yet it matters to the teams most likely to buy into a persistent graph: owners of generated Java trees and oversized monorepos.
Team-shared graph files have another cost. The README warns that the compressed artifact is rewritten on every index and Git stores each rewrite as a new blob. Its example reached about 6 GB of history across roughly 350 commits. Commit snapshots on a release cadence, ignore the directory, or set up Git LFS deliberately. Do not let an automatic watcher quietly become a repository-growth machine.
A September 28 push sits beside 646 open issues and pull requests
GitHub showed 45,402 stars and 3,720 forks on September 29, 2026. The last push landed on September 28, and v0.11.0 shipped on September 15. Search results separated the API's combined count into 474 open issues and 172 open pull requests. New reports and fixes were still moving on September 29, so the project is plainly maintained. The 646-item queue also shows how much surface its 45 agent integrations and broad parser coverage create.
Use codebase-memory-mcp when your agent repeatedly asks structural questions that grep answers poorly. Its local graph, 17 tools, and clean 47-test UI run make it worth a trial. Keep ordinary source reads in the loop for dead code, branch-sensitive work, and any change where a stale or merged symbol could cost more than the saved context.