How Multi-Repo CROSS_* Edge Linking Enhances Codebase Analysis

Multi-repo CROSS_ edge linking creates bidirectional graph edges between distributed repositories by matching HTTP routes, gRPC endpoints, async topics, and other service contracts across projects, enabling unified impact analysis and architectural visualization across entire codebase fleets.*

The Codebase Memory MCP (CBM) from DeusData constructs a semantic knowledge graph of symbols, files, and relationships for every indexed repository. When multiple repositories share the same store, the multi-repo CROSS_* edge linking capability automatically generates special cross-repo edges that transform isolated codebase graphs into a single interconnected system, dramatically expanding the depth and reach of static analysis.

What Are CROSS_* Edges?

CROSS_* edges are special relationship types created by the cross-repo pipeline that connect symbols across repository boundaries. Unlike standard intra-repo edges, these links explicitly model service contracts that span multiple codebases.

When the pipeline runs in multi-repo mode, it generates edges with the following types:

• CROSS_HTTP_CALLS – Links HTTP client calls in one repository to route handlers in another
• CROSS_ASYNC_CALLS – Connects async topic producers to consumers across projects (e.g., Kafka)
• CROSS_CHANNEL – Maps inter-process communication channels between services
• CROSS_GRPC_CALLS – Links gRPC client stubs to server implementations
• CROSS_GRAPHQL_CALLS – Connects GraphQL queries to resolver functions
• CROSS_TRPC_CALLS – Links tRPC procedure calls across TypeScript service boundaries

These edges are generated by the cross-repo pass implemented in src/pipeline/pass_cross_repo.c and recorded bidirectionally in both source and target project databases.

How Cross-Repo Linking Works

The cross-repo pipeline operates in three distinct phases to build these inter-repository bridges without duplication.

Route Matching Across Projects

For each HTTP_CALLS or ASYNC_CALLS edge discovered in the source project, the pipeline queries every target project's database for matching routes or async topics. When the qualified name (QN) of a route, channel, or endpoint matches between repositories, the system identifies a cross-repo contract.

This matching logic is orchestrated by cbm_cross_repo_match, declared in src/pipeline/pass_cross_repo.h and implemented in src/pipeline/pass_cross_repo.c.

Edge Construction and Properties

Once a match is identified, the pipeline constructs a JSON payload describing the relationship using build_cross_props. This payload includes:

• Target project name
• Target function and file path
• URL path or channel name
• Protocol-specific metadata

The resulting edge carries this metadata as properties, providing rich context for downstream analysis.

Bidirectional Upsertion

The insert_cross_edge function handles persistence using cbm_store_insert_edge, which upserts on a UNIQUE(source_id, target_id, type) constraint. This ensures:

• Zero duplication – Repeated indexing or incremental updates never inflate the graph
• Bidirectional visibility – The link appears from both sides without manual synchronization
• Idempotent builds – Re-running the pipeline produces deterministic results

Implementation in Codebase Memory MCP

The cross-repo functionality is integrated into the main pipeline flow in src/pipeline/pipeline.c, controlled by the CBM_DISABLE_LSP_CROSS environment variable. The following files comprise the core implementation:

File	Role
src/pipeline/pass_cross_repo.h	Public API exposing cbm_cross_repo_match
src/pipeline/pass_cross_repo.c	Core implementation: matching routes, building JSON payloads, and inserting CROSS_* edges
src/ui/http_server.c	Queries stores for CROSS_% edges to expose them via web UI and JSON APIs
docs/index.html / docs/EVALUATION_PLAN.md	Documentation describing cross-repo semantics and evaluation criteria

C API Example

Run cross-repo matching for a project against all other indexed repositories:

/* Match service-a against all other projects */
cbm_cross_repo_result_t res =
    cbm_cross_repo_match("service-a", (const char*[]){"*"}, 1);

/* Insert a CROSS_HTTP_CALLS edge (normally handled internally) */
insert_cross_edge(store,
                 "service-a",
                 caller_id,
                 handler_id,
                 "CROSS_HTTP_CALLS",
                 "{\"target_project\":\"service-b\",\"target_function\":\"handle\",\"target_file\":\"src/handler.py\"}");

Benefits to Analysis

Multi-repo CROSS_* edge linking provides concrete advantages for understanding distributed systems:

Discovery of service contracts – HTTP routes, gRPC methods, GraphQL operations, and channel contracts that span repositories become explicit graph edges. This allows automated impact analysis across service boundaries, making it trivial to identify which upstream services depend on a changing API.

Dependency tracing – CROSS_ASYNC_CALLS reveals async topics (e.g., Kafka) used by producers in one repo and consumers in another, exposing hidden runtime coupling that static imports cannot capture.

Architecture-wide metrics – Edge counts are aggregated via cbm_cross_repo_match and displayed in architecture reports, making it easy to spot "orphan" services, missing contracts, or excessive coupling between specific teams' codebases.

Cross-repo security review – Security tools can traverse CROSS_* edges to find all code paths that cross trust boundaries, simplifying attack-surface analysis by explicitly mapping entry points between services.

Visual navigation – The UI renders a multi-galaxy 3-D layout where each indexed repository appears as a galaxy and CROSS_* edges function as inter-galactic bridges. Engineers can jump from a node in Repo A directly to the linked node in Repo B, streamlining onboarding and debugging across microservices.

Querying CROSS_* Edges

You can retrieve cross-repo edges programmatically or via CLI.

Python API

Filter edges by type pattern to retrieve all cross-repository links:

# Retrieve all CROSS edges for a project

edges = store.get_edges(project="service-a", type_like="CROSS_%")
for e in edges:
    print(e.type, e.properties_json)

Command Line Interface

Generate a summary of cross-repo links for architectural review:

# Show summary of cross-repo links

codebase-memory-mcp --project service-a --summary --cross

Summary

• Multi-repo CROSS_ edge linking* bridges separate repositories by matching service contracts (HTTP, gRPC, GraphQL, async topics) across project boundaries
• Edges are generated by src/pipeline/pass_cross_repo.c and stored bidirectionally using cbm_store_insert_edge with UPSERT semantics to prevent duplication
• Supported edge types include CROSS_HTTP_CALLS, CROSS_ASYNC_CALLS, CROSS_CHANNEL, CROSS_GRPC_CALLS, CROSS_GRAPHQL_CALLS, and CROSS_TRPC_CALLS
• The UI queries CROSS_% edges to render a multi-galaxy 3D visualization, enabling direct navigation between repositories
• This capability exposes hidden runtime dependencies and enables cross-repo impact analysis, security tracing, and architectural metrics

Frequently Asked Questions

What are CROSS_* edges in Codebase Memory MCP?

CROSS_* edges are specialized graph relationships that connect code symbols across different repositories. When the cross-repo pipeline runs, it creates these edges (such as CROSS_HTTP_CALLS or CROSS_ASYNC_CALLS) to explicitly model service-to-service communication that spans codebase boundaries, transforming multiple isolated graphs into a unified knowledge graph.

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

The system uses cbm_store_insert_edge with a UNIQUE(source_id, target_id, type) constraint via the insert_cross_edge function. This upsert pattern ensures that repeated indexing or incremental updates never create duplicate relationships, keeping the graph size predictable and analysis fast regardless of how many times the pipeline runs.

Which service protocols are supported for cross-repo linking?

According to the source code in src/pipeline/pass_cross_repo.c, the system supports CROSS_HTTP_CALLS, CROSS_ASYNC_CALLS (for Kafka and similar message queues), CROSS_CHANNEL (for IPC), CROSS_GRPC_CALLS, CROSS_GRAPHQL_CALLS, and CROSS_TRPC_CALLS. These cover the majority of modern microservice communication patterns.

How does multi-repo linking improve security analysis?

Security tools can traverse CROSS_* edges to explicitly map all code paths that cross trust boundaries between services. This allows automated discovery of attack surfaces spanning multiple repositories, identification of sensitive data flows across service boundaries, and verification that authentication checks exist at every inter-service entry point.

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