# How Multi-Repo CROSS_* Edge Linking Enhances Codebase Analysis

> Boost codebase analysis with multi-repo CROSS_* edge linking. Unify impact analysis and visualize architecture across distributed repositories by matching service contracts.

- Repository: [Martin Vogel/codebase-memory-mcp](https://github.com/DeusData/codebase-memory-mcp)
- Tags: deep-dive
- Published: 2026-07-15

---

**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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.h) and implemented in [`src/pipeline/pass_cross_repo.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.h) | Public API exposing `cbm_cross_repo_match` |
| [`src/pipeline/pass_cross_repo.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.c) | Core implementation: matching routes, building JSON payloads, and inserting `CROSS_*` edges |
| [`src/ui/http_server.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/ui/http_server.c) | Queries stores for `CROSS_%` edges to expose them via web UI and JSON APIs |
| [`docs/index.html`](https://github.com/DeusData/codebase-memory-mcp/blob/main/docs/index.html) / [`docs/EVALUATION_PLAN.md`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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:

```c
/* 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:

```python

# 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:

```bash

# 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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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.