# How Cross-Repo Intelligence Links Projects with CROSS_* Edges in Codebase Memory MCP

> Discover how cross-repo intelligence links projects with CROSS_* edges in codebase-memory-mcp. Automatically find inter-service dependencies by scanning call types and build bidirectional links.

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

---

**Cross-repo intelligence in DeusData/codebase-memory-mcp automatically discovers inter-service dependencies by scanning HTTP_CALLS, ASYNC_CALLS, EMITS, GRPC_CALLS, GRAPHQL_CALLS, and TRPC_CALLS edges to create bidirectional CROSS_* edges that link matching routes, channels, and handlers across independently indexed repositories.**

The DeusData/codebase-memory-mcp project implements a sophisticated cross-repo intelligence system that transforms isolated project databases into a unified architectural graph. When projects have been indexed into individual SQLite databases, the pipeline analyzes outgoing calls from a source project and attempts to resolve them against incoming handlers in target projects. This process materializes explicit CROSS_* edges that make distributed microservice dependencies queryable and navigable from either direction.

## The Cross-Repo Matching Pipeline

The core implementation resides in [`src/pipeline/pass_cross_repo.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.c), exposing a public API through [`src/pipeline/pass_cross_repo.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.h). The entry point function `cbm_cross_repo_match` orchestrates the matching process across four distinct phases:

```c
cbm_cross_repo_result_t cbm_cross_repo_match(const char *project,
                                             const char **target_projects,
                                             int target_count);

```

([[`src/pipeline/pass_cross_repo.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.h)](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.h#L22-L30))

Before matching begins, the pipeline clears existing cross-repo edges for the source project using `delete_cross_edges` to prevent stale links. The matching process then executes four phases sequentially:

### Phase A: HTTP Route Matching

The scanner selects source edges of type **HTTP_CALLS** and derives canonical route identifiers using helpers like `cbm_route_canon_path` and `cr_url_path`. For example, a route such as `__route__GET__/v2/orders/{}` serves as the lookup key. The function `find_route_handler` searches target project databases for matching **Route** nodes, and upon successful discovery, creates a **CROSS_HTTP_CALLS** edge.

### Phase B: Async Topic Matching

Similar to HTTP matching, this phase scans **ASYNC_CALLS** edges and attempts to resolve them against **Route** nodes representing broker topics. The pipeline constructs canonical identifiers from broker and path combinations, creating **CROSS_ASYNC_CALLS** edges when matches are found.

### Phase C: Channel Matching

This phase handles bidirectional communication patterns by matching **EMITS** edges against **LISTENS_ON** relationships. The helper `try_match_channel_listener` identifies compatible channels across projects, resulting in **CROSS_CHANNEL** edges that represent pub/sub or event stream connections.

### Phase D: Generic RPC Matching

The final phase addresses modern RPC frameworks by scanning **GRPC_CALLS**, **GRAPHQL_CALLS**, and **TRPC_CALLS** edges. Each category maps to its corresponding edge type—**CROSS_GRPC_CALLS**, **CROSS_GRAPHQL_CALLS**, or **CROSS_TRPC_CALLS**—when matching route handlers are discovered in target repositories.

## Bidirectional Edge Creation with `insert_cross_edge`

For every successful match, the system creates edges in both databases to ensure bidirectional visibility. The static function `insert_cross_edge` handles the actual persistence:

```c
static void insert_cross_edge(cbm_store_t *store,
                              const char *project,
                              int64_t from_id,
                              int64_t to_id,
                              const char *edge_type,
                              const char *props) {
    cbm_edge_t edge = {
        .project = project,
        .source_id = from_id,
        .target_id = to_id,
        .type = edge_type,
        .properties_json = props,
    };
    cbm_store_insert_edge(store, &edge);      // upserts, avoiding duplicates
}

```

([[`src/pipeline/pass_cross_repo.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.c)](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.c#L125-L135))

The function `cbm_store_insert_edge` implements an upsert operation that respects the unique constraint on `(source_id, target_id, type)`, guaranteeing idempotence even when the pipeline runs multiple times. The JSON properties blob, constructed by `build_cross_props`, contains metadata describing the target project, handler name, source file, and URL path.

Forward and reverse edges are inserted separately to populate both the source and target databases:

```c
// Forward edge: source → target
char fwd[2048];
build_cross_props(fwd, sizeof(fwd),
                  tgt_project, handler_name, handler_file,
                  url_path, "url_path", method);

insert_cross_edge(src_store, src_project,
                  caller_id, local_route_id,
                  "CROSS_HTTP_CALLS", fwd);

```

([[`src/pipeline/pass_cross_repo.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.c)](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.c#L51-L56))

```c
// Reverse edge: target → source
char rev[2048];
build_cross_props(rev, sizeof(rev),
                  src_project, caller_name, caller_file,
                  url_path, "url_path", method);

insert_cross_edge(tgt_store, tgt_project,
                  handler_id, tgt_route_id,
                  "CROSS_HTTP_CALLS", rev);

```

([[`src/pipeline/pass_cross_repo.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.c)](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.c#L82-L86))

## Triggering Cross-Repo Analysis from the CLI

The MCP command-line interface exposes the cross-repo functionality through the `cross-repo` sub-command implemented in [`src/mcp/mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/mcp/mcp.c). The CLI invokes `cbm_cross_repo_match` and aggregates results for reporting:

```c
cbm_cross_repo_result_t result =
    cbm_cross_repo_match(project, targets, tp_count);
printf("Created %d HTTP, %d async, %d channel, %d gRPC, %d GraphQL, %d tRPC cross‑repo edges.\n",
       result.http_edges, result.async_edges, result.channel_edges,
       result.grpc_edges, result.graphql_edges, result.trpc_edges);

```

([[`src/mcp/mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/mcp/mcp.c)](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/mcp/mcp.c#L3391-L3396))

The result structure provides counts per edge type, number of projects scanned, and total execution time. The top-level MCP command surfaces these statistics in architecture reports ([[`mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/mcp.c)](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/mcp/mcp.c#L2462-L2470)) while logging completion via `cbm_log_info("cross_repo.done", …)`.

## Querying CROSS_* Edges in the Database

The HTTP server implemented in [`src/ui/http_server.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/ui/http_server.c) exposes endpoints that retrieve cross-repo relationships for visualization. The underlying SQL query filters the `edges` table for CROSS_* relationships:

```sql
SELECT type, source_id, target_id, properties_json
FROM edges
WHERE project = ?1 AND type LIKE 'CROSS_%';

```

([[`src/ui/http_server.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/ui/http_server.c)](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/ui/http_server.c#L1318-L1330))

This query enables the web interface to render cross-repository dependencies, showing developers exactly which external services consume or provide specific endpoints, topics, and channels.

## Summary

- **Cross-repo intelligence** operates through a four-phase pipeline that matches HTTP calls, async topics, channels, and RPC calls against target project databases.
- The `cbm_cross_repo_match` function in [`src/pipeline/pass_cross_repo.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.h) coordinates discovery, while `insert_cross_edge` handles persistence in [`src/pipeline/pass_cross_repo.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.c).
- **Bidirectional CROSS_* edges** are created in both source and target databases to ensure navigability from either direction.
- The system guarantees **idempotence** through unique constraints on `(source_id, target_id, type)` and clears stale edges before each run.
- Results are exposed via CLI reports and SQL queries against the `edges` table, making cross-service dependencies visible in architecture reports.

## Frequently Asked Questions

### How does the system prevent duplicate CROSS_* edges when re-running the analysis?

The `cbm_store_insert_edge` function performs an upsert operation that respects the unique constraint on the combination of `source_id`, `target_id`, and `type` in the `edges` table. Additionally, the pipeline calls `delete_cross_edges` at the start of each run to clear existing CROSS_* edges for the source project, ensuring that only current, valid relationships remain in the database.

### What types of communication patterns can be linked across repositories?

The system supports six distinct communication patterns: **HTTP** (REST endpoints), **Async** (message broker topics), **Channel** (pub/sub event streams), **gRPC**, **GraphQL**, and **tRPC**. Each pattern generates a specific edge type—CROSS_HTTP_CALLS, CROSS_ASYNC_CALLS, CROSS_CHANNEL, CROSS_GRPC_CALLS, CROSS_GRAPHQL_CALLS, or CROSS_TRPC_CALLS—based on the underlying transport mechanism detected in the source code.

### Where is the cross-repo matching logic implemented in the codebase?

The primary implementation resides in [`src/pipeline/pass_cross_repo.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.c), which contains the four-phase matching logic and the `insert_cross_edge` function. The public API is declared in [`src/pipeline/pass_cross_repo.h`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/pipeline/pass_cross_repo.h). The CLI entry point that invokes this logic is located in [`src/mcp/mcp.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/mcp/mcp.c), while the web interface query is implemented in [`src/ui/http_server.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/src/ui/http_server.c).

### How does the pipeline derive canonical identifiers for matching routes?

The system uses helper functions such as `cbm_route_canon_path` and `cr_url_path` to normalize route patterns into canonical forms like `__route__GET__/v2/orders/{}`. These canonical identifiers abstract away implementation-specific differences, allowing the matcher to correctly link HTTP callers in one repository with route handlers in another even when path parameters or formatting conventions vary.