
A frontend calls an API. That API invokes another service. A queue triggers a worker somewhere else. One change can cross four repositories before the feature is complete.
The problem isn't getting another coding agent. It's giving the agent you already use enough context to follow the feature across repositories.
1. Organisation-Wide Indexing
Cross-repo development should not begin with the developer figuring out which repositories to open. Once an organisation connects its repositories to CodeZero, those repositories are indexed and available as context.
For a feature spanning web-app, checkout-service, payment-service, invoice-worker, and shared-types, CodeZero can navigate the pieces that matter:
- symbols, definitions, imports, and references
- HTTP routes and outbound calls
- queues and consumers
- database access and service references
The cross-repository relationships are then worked out from those indexes when the agent needs them. The developer asks the question; the repositories are already ready to search.
2. Route Matching + Service References
API routes are one of the clearest relationships that can cross repositories. If one repository calls:
GET /repos/status
and another exposes:
/api/v1/code/repos/status
CodeZero can compare the route structure, account for prefixes and dynamic parameters, and connect the caller to the likely service.
But route matching fails when requests are hidden behind shared clients, SDKs, hooks, or configuration. That is why CodeZero uses a second signal: declared service references.
config.getOrThrow('USER_SERVICE_URL')
Names such as USER_SERVICE_URL, PAYMENT_API_URL, or AUTH_ENDPOINT can reveal that a repository depends on another service even when no literal URL sits next to the HTTP call.
Route matching finds the connection when the call is visible. Service references help when abstraction hides it.
3. Cross-Repository Graph
Once those signals are combined, repositories stop looking like separate folders and start looking like one feature path.
web-app
|
v
checkout-service
|
v
payment-service
|
v
payment.completed
|
v
invoice-worker
The useful part is not just knowing that payment-service exists. It is knowing who calls it, what it calls, and which repositories depend on it.
That changes a question like "Can I change this response?" into "Which repositories consume this response, and what else needs to change with it?"
4. Confidence Scoring
Cross-repository relationships cannot always be proven from one signal. If /auth/validate exists in three repositories, a route match alone does not identify the intended target.
CodeZero combines evidence such as route matches, declared service references, repository context, call-site names, and ambiguity before deciding how strongly to expose a relationship.
| Signal | What it adds |
|---|---|
| Route match | Caller and endpoint structure line up |
| Service reference | The calling repo explicitly names a dependency |
| Call context | Client/file/symbol names reinforce the target |
| Ambiguity | Multiple plausible targets lower confidence |
A guessed edge presented as fact can send an agent into the wrong repository. An uncertain edge presented as uncertain tells the agent to investigate further.
5. MCP Context
WHAT IS MCP?
Model Context Protocol (MCP) is a standard interface that lets AI applications discover and call external tools and retrieve context.
CodeZero exposes organisation-level code intelligence through MCP, so Claude Code or Codex can retrieve context beyond the repository currently in front of the agent.
Without CodeZero
Claude Code / Codex
|
v
Current repository
|
v
Generate change
With CodeZero
Claude Code / Codex
|
v
CodeZero
|
v
Repo index + dependency graph
|
v
Relevant code across repos
The coding model still plans and writes the change. CodeZero gives it a wider map before it does that.
6. One Question, Multiple Repositories
Consider a developer asking:
Can I change the response returned by
GET /checkout/status?
Identify endpoint → Find callers → Find dependent repos → Find shared types → Build change context
GET /checkout/status
Consumed by:
- web-app
- mobile-app
- admin-dashboard
Shared contract:
- checkout-types
Now the agent has the blast radius before it edits the first file. That is the practical difference between repo-local coding and cross-repository development.
7. Unknown Is Not No Dependency
Cross-repo mapping becomes dangerous when missing information is treated as proof that nothing exists.
"There is a dependency here, but we cannot confidently place it."
is not the same as
"There is no dependency."
If a repository declares another service but CodeZero cannot confidently map it to a repository, that relationship can remain unresolved. Developer confirmations and corrections can then be reused instead of forcing the same ambiguity to be solved again later.
Same agent. Same workflow. A wider, evidence-backed view of the codebase.
Explore CodeZero
Use the coding agent you already have with organisation-level code context before the first edit.
Related in this series: How CodeZero Finds the Right Context Across 10K Files and 1M Functions.