Repository navigation
Description
Version
codebase-memory-mcp 0.8.1
Platform
Windows (x64)
Install channel
GitHub release archive / install.sh / install.ps1
Binary variant
standard
What happened, and what did you expect?
After indexing I tasked my agent to find dead code. It started calling the mcp and it has crashed almost on the first useful query.
Reproduction
It is a private codebase. I had to check the box that it is not. I am doing so in the hopes that it might help anyway.
codebase-memory-mcp cli query_graph '{"project": "YYY", "query": "MATCH (f:Function) WHERE NOT f.file_path CONTAINS ''ext'' AND NOT f.file_path CONTAINS ''Tests'' AND NOT f.file_path CONTAINS ''examples'' AND NOT f.name = ''main'' OPTIONAL MATCH (c)-[:CALLS]->(f) WITH f, c WHERE c IS NULL RETURN f.name, f.qualified_name, f.file_path, f.start_line ORDER BY f.file_path LIMIT 50"}'
no usefull output, just a crash dump appearing in AppData\Local\CrashDumps\
Logs
PS C:\Users\XXX\AppData> codebase-memory-mcp cli query_graph '{"project": "YYY", "query": "MATCH (f:Function) WHERE NOT f.file_path CONTAINS ''ext'' AND NOT f.file_path CONTAINS ''Tests'' AND NOT f.file_path CONTAINS ''examples'' AND NOT f.name = ''main'' OPTIONAL MATCH (c)-[:CALLS]->(f) WITH f, c WHERE c IS NULL RETURN f.name, f.qualified_name, f.file_path, f.start_line ORDER BY f.file_path LIMIT 50"}'
level=info msg=mem.init budget_mb=32596 total_ram_mb=65192
PS C:\Users\XXX\AppData>
Project scale (if relevant)
Nodes: 29,361 Edges: 59,940
Confirmations
- I searched existing issues and this is not a duplicate.
- My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.
Activity
zbynekwinkler commentedon Jun 25, 2026
I think I have it crashing also under wsl.
zbynekwinkler commentedon Jun 25, 2026
That is actually a local build of current main.
zbynekwinkler commentedon Jun 25, 2026
I asked the agent to try to minimize the crashing query:
zbynekwinkler commentedon Jun 25, 2026
btw: It is a really slow to rebuild. Iterating on a fix is not as fast as it could be.
test(repro): crash + trace + gitignore reproductions for #627, #514, #…
zbynekwinkler commentedon Jun 26, 2026
I had my agent take a look and it was able to generate some kind of a fix (let me know if you are interested in it). I had the original agent testing it on the private repo and after a couple of iterations, they fixed it. This is the final report:
Details
Here is the complete, comprehensive list of **all four bugs/limitations** we identified and diagnosed in the graph engine during this session:1. 🔴 Bare Variable-Binding Corruption (Fixed)
WITHclause (e.g.,WITH forWITH f AS func) stripped its property map and bound the variable to a literal string equal to its own identifier name (e.g.,"f"or"func"). Any subsequent property lookup (f.qualified_name) evaluated to that string.2. 🔴 Traversal Outer-Join Process Crash (Fixed)
OPTIONAL MATCH(outer-join/null-padding traversal) over large node/relationship collections crashed the server binary withConnection closed. This was isolated as a crash in the optional matching planner/traversal executor itself, separate from anyWITHorWHEREoperations.3.⚠️ Cypher Parser Nesting Limitations (Constraint)
WHEREclauses (e.g.,WHERE NOT (f)<-[:CALLS]-()throws anunexpected operatorerror).WHERE; use explicit MATCH structures or property filtering instead.4.⚠️ Inline Projections Logic Errors (Constraint)
WITHprojections (e.g.,WITH (r IS NULL) AS is_uncalledthrowsexpected token type 85, got 66orWITH 1 AS xthrowsexpected token type 0, got 13).WITH f.qualified_name AS qname, caller.name AS caller_name) which evaluates correctly, and run subsequent operations on those primitives.I also have several handoff documents from the session.
I see that you most likely have a fairly good idea what is going on given the recent 2534f3b, so let me know if you want any more of this.
DeusData commentedon Jun 27, 2026
Hey @zbynekwinkler, yes currently looping through all the issues and trying to find ways to reproduce all the issues and fix them once and for all. Also having some other people on it. Still, would be interested if you could share your reports :) Always helpful to get more information
DeusData commentedon Jun 28, 2026
This issue now has a first-class, durable reproduction in the cumulative bug-reproduction suite landing in #667 — a test that pins the exact failing behaviour, so it's tracked and guarded against silent regression. Where #667 also lands the root-cause fix, that's called out in the PR; otherwise the reproduction makes the eventual fix straightforward and verifiable.
The reproduction goes live once #667 merges. (Posted from the release branch's QA pass.)
fix: 17 reproduce-first issue + new-bug fixes (per-case verified)
style: clang-format issue-batch additions (cypher/mcp)
zbynekwinkler commentedon Jun 29, 2026
The commits my agent produced are a99a419 and 3fd3543. I'll try to dig up the handoff as well later (they are on a different computer).
zbynekwinkler commentedon Jun 29, 2026
I see
got merged. I'll try to verify the fix.
rudi193-cmd commentedon Jul 5, 2026
Related consumer mitigation + safer dead-code query shape
Same crash class as #601 — we hit this during a June fleet structural audit on v0.8.1 when an agent issued a whole-graph
OPTIONAL MATCHanti-join for dead-code discovery.What we do now (willow-2.0
sap/cbm_facade.py):count(*),coalesce(),<-, etc.)LIMITwhen missing onquery_graphSafer dead-code pattern (forward-only, bounded — not a full fix for server-side robustness):
Still requires grep confirmation for aliased imports (#875) and common-name fan-in (#725), but avoids the whole-graph
OPTIONAL MATCH (c)-[:CALLS]->(f) WITH f, c WHERE c IS NULLshape from the original report.Public fixture: willow-2.0 (~17.8k nodes). Audit notes:
docs/audits/CODEBASE_MEMORY_MCP_TOOL_EVAL_ADDENDUM_2026-07-05.md. Related filing: #873 (DISTINCT ordering, refs #237).fix(cypher): bound OPTIONAL fallback in expand_pattern_rels to preven…
fix(cypher): expansion materializes every matched row — the cap falsi…
DeusData commentedon Sep 25, 2026
Thank you, @zbynekwinkler, for the report and the minimization, @rudi193-cmd for the safer query shape, and everyone who shared findings!
Your query no longer crashes on current main, but it did still return wrong values: a node passed through
WITHbecame a name-only stub, sof.qualified_namecame back as"f". That's fixed in a change now in review (#2351); with it, your exact dead-code query returns the right rows.While checking, we found one more bug: in a
WITHstage,count(c)counts the empty OPTIONAL MATCH row, soWHERE inbound = 0finds nothing. @zbynekwinkler, you have commits in your fork around this; if you'd like to open a PR for that part, you're very welcome to. Otherwise we'll fix it next. Nested pattern predicates (WHERE NOT (f)<-[:CALLS]-()) and expression or literal projections inWITHaren't supported yet; we'll track them as feature requests.DeusData commentedon Oct 19, 2026
Thank you again for the minimized query and contribution details. The September update distinguishes the crash,
WITHvalue preservation, optional-row counting, and unsupported syntax; those should not be treated as one completed fix. I have no new verification result for the remaining cases to announce today.DeusData commentedon Oct 25, 2026
Thank you for your patience. Sorry for the delay. The remaining WITH/counting semantics and unsupported syntax need separate maintainer follow-up rather than a blanket crash-fix claim. I’ll follow up soon.