How Cross-Repo Intelligence Works in codebase-memory-mcp: The CROSS_* Edge Architecture

Cross-repo intelligence in codebase-memory-mcp operates through a dedicated indexing pass that discovers matching HTTP routes, async topics, and channel emit/listen pairs across all indexed repositories, creating bidirectional CROSS_* edges stored in each project's SQLite database to enable unified multi-repository queries.

codebase-memory-mcp constructs a unified knowledge graph that spans multiple independent repositories by leveraging cross-repo intelligence capabilities. This system enables AI agents to trace service dependencies beyond repository boundaries by identifying matching service endpoints and creating specialized edges that link related code across projects. The implementation centers on the pipeline pass defined in src/pipeline/pass_cross_repo.c, which automatically generates CROSS_* edge types to make inter-repository connections queryable with the same sub-millisecond latency as intra-repo relationships.

The Cross-Repo Discovery Pipeline

The cross-repo intelligence system relies on a dedicated pipeline pass that runs during indexing to discover connections between service-level constructs across project boundaries.

Discovery and Canonicalisation

For every HTTP_CALLS, ASYNC_CALLS, or EMITS edge in a source project, the pass searches the graph of every target project for a matching Route or Channel node. According to the source code comments in src/pipeline/pass_cross_repo.c (lines 1-12), this discovery phase iterates through all indexed projects to find potential matches.

Before matching, HTTP URLs undergo canonicalisation to ensure compatibility across different deployment environments. The cr_url_path helper function (lines 43-53) strips the host portion from URLs, reducing them to their path component (e.g., /v2/x), because the host may differ between services while the path remains consistent.

Bidirectional Edge Creation

When a match is found, the system creates bidirectional edges to ensure visibility from either repository. The insert_cross_edge function inserts the edge into both the source and target SQLite stores simultaneously. This design guarantees that every repository can answer queries locally without requiring a central server.

The edges are idempotent—unique on the combination of (source_id, target_id, type)—so running the pass repeatedly does not duplicate rows (lines 21-28). Before recomputing links for a project, the pass removes all existing CROSS_* edges to eliminate stale connections (lines 11-18).

Supported Edge Types

The engine currently supports six distinct cross-repo edge types, enumerated in src/mcp/mcp.c (lines 2818-2822):

• CROSS_HTTP_CALLS
• CROSS_ASYNC_CALLS
• CROSS_CHANNEL
• CROSS_GRPC_CALLS
• CROSS_GRAPHQL_CALLS
• CROSS_TRPC_CALLS

Each edge carries a JSON payload built by build_cross_props (lines 90-108) describing the target project, function, file, and protocol details such as URL path and HTTP method.

Storage Architecture for CROSS_* Edges

All CROSS_* edges live in the same SQLite edges table as standard edges, distinguished only by their type string and rich JSON payload. Each repository maintains its own SQLite file named <project>.db in the cache directory.

The pass opens both the source and target database files during execution, inserts the edge into each, and closes them independently. This distributed storage model ensures that cross-repo intelligence remains available even when querying a single repository offline, as the edges are physically stored in both endpoints of the relationship.

Querying Cross-Repository Connections

The MCP API exposes search_graph, trace_path, and get_architecture tools that automatically include CROSS_* edges when traversing the graph. When any tool is called with a project parameter, the underlying Cypher-like engine includes these inter-repository links in the results.

For example, to find all services that call a specific HTTP endpoint across any indexed repository:

{
  "tool": "query_graph",
  "params": {
    "project": "my-project",
    "query": "MATCH (src)-[:CROSS_HTTP_CALLS]->(tgt) WHERE src.name = 'fetchUser' RETURN tgt.project, tgt.name, tgt.properties_json"
  }
}

The response includes the target_project field extracted from the edge payload, allowing agents to surface multi-repo call chains. The UI endpoints in src/ui/http_server.c (lines 1318-1330) also fetch distinct target projects from CROSS_* edges for visualization purposes.

Integration with AI Agents

During indexing, the install command automatically enables the cross-repo pass for every newly indexed project. Agents such as Claude Code, Codex CLI, and Gemini CLI receive this context via the PreToolUse hook. When an agent asks "what calls ProcessOrder?", the server traverses both intra-repo CALLS edges and inter-repo CROSS_HTTP_CALLS edges, returning a unified answer that spans repository boundaries.

Implementation Examples

Manual Edge Insertion

While typically automated, you can manually insert cross-repo edges using the internal API:

// Assume `store` points to the source project's SQLite store.
const char *props = NULL;
char buf[2048];
build_cross_props(buf, sizeof(buf),
                 "target-repo",   // target project name
                 "handlerFunc",   // target function name
                 "src/file.go",   // target file
                 "/api/v1/items",// URL or channel identifier
                 "method", "GET"); // optional extra key/value
props = buf;

insert_cross_edge(store, "source-repo", caller_id, handler_id,
                  "CROSS_HTTP_CALLS", props);

CLI Query for Cross-Repo HTTP Calls

List all cross-repo HTTP edges for a specific project:

codebase-memory-mcp cli query_graph '{
  "project":"my-repo",
  "query":"MATCH (s)-[e:CROSS_HTTP_CALLS]->(t) RETURN s.name, e.type, t.project, t.name, e.properties_json"
}'

Python Client Integration

Retrieve cross-repo call paths using the official client:

from codebase_memory_mcp import MCPClient

client = MCPClient()
result = client.query_graph(
    project="my-repo",
    query=(
        "MATCH (src)-[:CROSS_HTTP_CALLS]->(tgt) "
        "WHERE src.name = 'fetchUser' "
        "RETURN tgt.project AS target_repo, tgt.name AS target_fn, tgt.properties_json"
    )
)
print(result["results"])

Integration tests in tests/repro/repro_issue523.c validate the insertion and deduplication logic, while tests/test_integration.c (lines 386-409) demonstrates seeding edges in synthetic test scenarios.

Summary

• Cross-repo intelligence in codebase-memory-mcp is implemented via a dedicated pipeline pass in src/pipeline/pass_cross_repo.c that matches service endpoints across repositories.
• The system creates bidirectional CROSS_* edges (HTTP, Async, gRPC, GraphQL, tRPC, and Channel) stored in each project's SQLite database.
• Canonicalisation via cr_url_path ensures URL matching works across different deployment environments by stripping host portions.
• Edges are idempotent and include rich JSON metadata built by build_cross_props, with automatic cleanup of stale connections during re-indexing.
• AI agents query these edges through standard MCP tools (search_graph, trace_path) with no additional latency compared to intra-repo queries.

Frequently Asked Questions

What are the specific CROSS_* edge types supported by codebase-memory-mcp?

The system supports six cross-repo edge types: CROSS_HTTP_CALLS, CROSS_ASYNC_CALLS, CROSS_CHANNEL, CROSS_GRPC_CALLS, CROSS_GRAPHQL_CALLS, and CROSS_TRPC_CALLS. These are enumerated in src/mcp/mcp.c (lines 2818-2822) and correspond to different service communication protocols that can span repository boundaries.

How does the system prevent duplicate cross-repo edges when re-indexing?

The cross-repo pass is idempotent by design, using a unique constraint on the combination of (source_id, target_id, type). Additionally, the pass clears all existing CROSS_* edges for a project (lines 11-18 in src/pipeline/pass_cross_repo.c) before computing new matches, ensuring no stale connections persist between indexing runs.

Can I query cross-repo connections without running a central server?

Yes. Because CROSS_* edges are stored bidirectionally in each repository's local SQLite file (<project>.db), you can query inter-repository relationships while working with a single database offline. The pass inserts the edge into both the source and target stores, making the link visible from either side without requiring network access to other repositories.

What happens when an HTTP endpoint changes its path in the target repository?

When re-indexing occurs, the cleanup phase removes all existing CROSS_* edges for the affected project (lines 11-18), and the discovery phase recomputes matches based on the current state of all indexed repositories. If the path no longer matches the canonicalised pattern, the edge will not be recreated, effectively removing the stale connection from the graph.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}