Feature Request: Cross-Repository Context for Copilot (Web ↔ Microservice)

[prateek-odev]

Select Topic Area

General

Copilot Feature Area

Copilot Coding Agent

Body

Hi,

I’d like to request improved cross-repository context support in GitHub Copilot, specifically for scenarios where one repository logically depends on another (e.g., a web app consuming a microservice).

Use Case

Example setup:

web-app repository (frontend)

orders-service repository (microservice API)

The web app:

Calls API endpoints from the microservice

Depends on DTOs / contracts defined in the service

Must stay aligned with backend route changes, payload changes, and validation rules

When updating the microservice (e.g., modifying an endpoint response or renaming a field), I also need to update the web app accordingly.

Today, Copilot:

Works within a single repository context

Cannot reason about API contracts defined in another repo

Cannot validate whether frontend usage matches backend changes

Cannot assist with coordinated changes across both repos

Proposed Capability

Allow Copilot to understand explicit cross-repo relationships, such as:

Declaring that web-app depends on orders-service

Linking specific branches across repositories

Sharing indexed context between selected repositories

Enabling agent tasks that reason across multiple repos

For example:

If I change a response model in orders-service, Copilot could suggest required updates in web-app

If the web app calls a missing or outdated endpoint, Copilot could detect mismatch against the service repo

Agent tasks could optionally operate across multiple repos for a single feature or issue

Why This Matters

Modern architectures frequently split systems into multiple repositories:

Frontend + backend

Multiple microservices

Shared SDK / contract repositories

Copilot is very powerful within a single repo, but architectural reasoning often spans repository boundaries. Supporting cross-repo context would:

Reduce integration bugs

Improve contract consistency

Enable safer API evolution

Make Copilot more effective for distributed systems

Is this currently on the roadmap?
Are there recommended best practices to approximate this behavior today?

[DanielWestgaard]

Hey @prateek-odev, solid writeup. I think your use case is exactly right.

Some notes for anyone landing here from a search.

State of the art today. No mainstream agent (Copilot, Cursor, Claude Code, Codex) handles cross-repo context out of the box. Several teams have published their own approaches in the last six weeks, and the diagnoses converge:

• Augment Code, How we built a high-quality AI code review agent (Mar 10): lists cross-repo context as a corner case their review agent handles via the Augment Context MCP, which exposes their context engine to other agents.
• Neilos (username), How I Manage 15+ Repos with Claude Code (Without Losing My Mind) (Mar 27): solo operator, 15+ repos, 10 Claude Code agents. Built a manager/worker layer with isolated git worktrees.
• Harness, Your Repo Is a Knowledge Graph. You Just Don't Query It Yet (Apr 1): argues SCM is becoming "Source Context Management" — the codebase as a queryable graph rather than a file store.
• Meta, How Meta used AI to map tribal knowledge in large-scale data pipelines (Apr 6): cross-repo dependency index turned "what depends on X" from ~6,000 tokens to ~200 tokens.
• Mabl, How We Built a System for AI Agents to Ship Real Code Across 75+ Repos (Apr 8, with a Part 2 on Apr 28): 25 engineers, 100+ repos. An 850-line Repo Coordination Graph that agents query at planning time; reduced context drift from ~40% of failures to <5%.

I wrote up the convergence pattern across the three war stories here if it's useful.

Approximating cross-repo context today, three rough categories of workaround:

1. Workspace bundling. Pull dependent repos into one workspace (pnpm workspaces, git worktrees, the "virtual monorepo" pattern). Cheapest path, works for ≤3 repos, breaks down at scale or across language boundaries.
2. Coordination layer in the agent itself. Neil's ttal approach: manager agent holds the cross-repo plan, workers only write to one repo at a time. Works for solo operators, doesn't survive 25-engineer scale.
3. Dependency graph as runtime infrastructure. Mabl and Meta both built the graph explicitly. Augment Context MCP gives you a hosted version of this if you can change IDE. This is also what I work on at Riftmap — auto-discovered from a GitHub or GitLab token, queryable via HTTP API, aimed at exactly the orders-service ↔ web-app DTO drift case you described. Agent integration docs.

For your specific setup (web-app + microservice with shared contracts), workspace bundling is the cheapest first step. It stops scaling once you have a shared SDK repo or 5+ services.

Disclosure: I work on Riftmap, but this is a genuine answer to your "best practices today" question. Happy to compare notes. Hope some of it helps!

---

edit (Jun 2026): I turned this into a full writeup — How to give GitHub Copilot cross-repo context today, the long version of this answer, with each of the three workarounds set up end-to-end and an honest note on where each one stops.