cgc index . says repo "exists but has no files" immediately after successful cgc index --force . #701

Summary

cgc index . reports:

Repository '.' exists but has no files (likely interrupted). Re-indexing...

even when run immediately after a successful cgc index --force . against the same repository.

This makes it look like the index is not persisting correctly, or that cgc is mis-detecting the repo state on the next run.

Environment

• CodeGraphContext: 0.3.0
• Neo4j: Docker image neo4j:5.21
• OS: macOS 26.3.1
• Architecture: x86_64
• Install method: pipx

Database config

Using the global CGC config in ~/.codegraphcontext/.env:

DEFAULT_DATABASE=neo4j
NEO4J_URI=neo4j://localhost:7687
NEO4J_USERNAME=neo4j

I also removed separate Codex MCP env overrides so the CLI and MCP are not using different DB settings.

Reproduction

From the repo root:

cgc --version
cgc index --force .
cgc index .

Actual behavior

First command succeeds:

Loaded configuration from: /Users/.../.codegraphcontext/.env
Using database: Neo4j
Force re-indexing (--force flag detected)
Initializing services and database connection...
Services initialized.
Deleting existing index for: /Users/.../modulith
✓ Deleted old index
Re-indexing: /Users/.../modulith

Successfully re-indexed: . in 74.58 seconds

Then the very next plain index says the repo has no files:

Loaded configuration from: /Users/.../.codegraphcontext/.env
Using database: Neo4j
Initializing services and database connection...
Services initialized.
Repository '.' exists but has no files (likely interrupted). Re-indexing...
Starting indexing for: /Users/.../modulith

Successfully finished indexing: . in 58.05 seconds

This happens repeatedly.

Expected behavior

After a successful cgc index --force ., a subsequent cgc index . should detect a healthy existing index and should not say the repository has no files.

Additional notes

I also observed inconsistent graph state after indexing:

• repository stats reported 0 files / 0 functions / 0 classes / 0 modules
• but code search could still return real hits from the repository

That may be related to the same underlying issue.

Probable root cause

This looks like a false negative in the CLI's "already indexed" check, not necessarily a failed index write.

In the installed cgc 0.3.0 source, the relevant code is in codegraphcontext/cli/cli_helpers.py:

result = session.run(
    "MATCH (r:Repository {path: $path})-[:CONTAINS]->(f:File) RETURN count(f) as file_count",
    path=str(path_obj)
)

That query only counts direct Repository -> File relationships.

However, the graph builder appears to model most files under directories, e.g.:

• Repository -> Directory -> ... -> File

not necessarily:

• Repository -> File

In my local Neo4j data for this repository, a direct query showed:

direct_files, nested_files
0, 156

So the repository is not empty. It has files reachable through transitive [:CONTAINS*] paths, but the CLI check only looks one hop deep and therefore concludes incorrectly
that the repo "has no files".

This matches the observed behavior exactly:

1. cgc index --force . succeeds
2. immediate cgc index . checks only direct Repository -> File
3. query returns 0
4. CLI prints Repository '.' exists but has no files (likely interrupted). Re-indexing...

Suggested fix

The file-count query in the CLI should probably use a transitive CONTAINS traversal instead of a single hop.

Current logic appears to be equivalent to:

MATCH (r:Repository {path: $path})-[:CONTAINS]->(f:File)
RETURN count(f) as file_count

Suggested replacement:

MATCH (r:Repository {path: $path})-[:CONTAINS*]->(f:File)
RETURN count(DISTINCT f) as file_count

Using DISTINCT would also avoid overcounting if there are multiple paths.

This would align the "already indexed" check with the actual graph shape created by the indexer and with other parts of the codebase that already use transitive [:CONTAINS*]
traversal for repository stats.