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

> Discover how cross-repo intelligence works in codebase-memory-mcp with CROSS_* edges. Learn how it unifies multi-repo queries by indexing and connecting elements across all your projects.

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

---

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

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

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

```bash
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:

```python
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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/tests/repro/repro_issue523.c) validate the insertion and deduplication logic, while [`tests/test_integration.c`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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`](https://github.com/DeusData/codebase-memory-mcp/blob/main/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.