Skip to content

init silently reports success on an unsupported-language project (0 files, index_state: complete) #1502

Description

@rjvkn

If a project is entirely in a language codegraph doesn't support, codegraph init scans it, finds nothing it can parse, and reports success anyway: index_state: complete, 0 files, no warning. From an MCP client (or a human) that looks identical to "indexed fine, your query just didn't match anything", since codegraph_explore comes back empty either way.

Repro:

mkdir demo && cd demo
printf 'module demo::vault { public fun f() {} }\n' > a.move
codegraph init          # "Indexed 0 files", exits 0, index_state: complete
codegraph explore "f"   # empty, no hint that .move isn't supported

(Any unsupported language does it, Move's just my case.)

Why it stings: an agent wired up over MCP burns a few calls concluding "no matches" before it works out, usually by poking at the SQLite db, that codegraph never parsed the files at all. There's no way to tell "codegraph is inactive for this tree" apart from "codegraph is active and found nothing."

Would be great if a 0-files-but-non-empty-workspace init surfaced that, maybe a one-liner on init and in codegraph_explore:

No supported source files were indexed (42 files present, no matching grammar). codegraph is inactive for this workspace.

Listing the extensions it saw but skipped would be a nice bonus. Nothing needs to change on the happy path.

codegraph 1.5.0, linux-x64.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions