C/C++ #include not mapped as IMPORTS edges — expected or a bug?

[Zeermil]

Version

codebase-memory-mcp 0.9.0

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

ui

What happened, and what did you expect?

I indexed a mixed C++/Kotlin/Python project using codebase-memory-mcp v0.9.0 on Windows.

Kotlin/Python files get IMPORTS edges correctly
C++ files — none of the #include directives produce IMPORTS edges in the graph
Example: main.cpp #includes NodeController.h, but the graph only shows IMPORTS from main.cpp to NodeController.cpp (Module node), not to the header file. Most C++ .cpp and .h files end up with zero incoming edges.

Query:

MATCH (f:File) WHERE NOT EXISTS { (f)<-[:IMPORTS|CALLS|CONTAINS_FILE|DEFINES|USAGE]-() } RETURN count(f)
Returns 194 out of 214 total files, even though most of those are actively used via #include in the build system.

My setup:

Platform: Windows (amd64)
Binary: codebase-memory-mcp v0.9.0 (windows-amd64, static binary)
Project type: PlatformIO (C++/Arduino) + Android (Kotlin) + Python backend
Index mode: full, CBM_WORKERS=1 (no crashes, status: "indexed")

Is missing C/C++ #include → IMPORTS mapping a known limitation?
Are C/C++ #include dependencies tracked under a different edge type that I'm missing?
Is there a workaround or pending fix for this?
Thanks!

Reproduction

none

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

4028 nodes / 15847 edges / 214 files

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.

[DeusData]

Thanks for the detailed C/C++ import report. Triage: treating this as a C/C++ import extraction bug rather than expected behavior. Header includes are real dependency edges for impact analysis, and the current graph shape makes many active files look disconnected. Added to 0.9.1-rc; the fix should include a small C/C++ fixture for include-to-header IMPORTS edges and avoid confusing header targets with same-named module/source nodes.