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

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, exposing a public API through src/pipeline/pass_cross_repo.h. The entry point function cbm_cross_repo_match orchestrates the matching process across four distinct phases:

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

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

// 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#L51-L56))

// 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#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. The CLI invokes cbm_cross_repo_match and aggregates results for reporting:

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#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/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 exposes endpoints that retrieve cross-repo relationships for visualization. The underlying SQL query filters the edges table for CROSS_* relationships:

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#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 coordinates discovery, while insert_cross_edge handles persistence in 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, 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. The CLI entry point that invokes this logic is located in src/mcp/mcp.c, while the web interface query is implemented in 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.

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