GitHub Copilot Across
Multiple Repositories
Copilot has three mechanisms that reach across repositories, and they behave differently on every surface. This page is the surface-by-surface answer: what each one can see, where each one stops, and the question all three hand back to you.
Partly, and it depends on the surface. Copilot Chat in VS Code reaches across repositories through a multi-root workspace. Copilot Spaces is natively multi-repo. The Copilot cloud agent is not: GitHub documents that it "cannot make changes across multiple repositories in one run".
All three end in the same place — a list of repositories somebody chose by hand. The folders array in a workspace file, the sources list in a Space, the repo scope on an agent's token. Choosing that list correctly is the blast-radius question, and it is the one part Copilot does not help with.
What each Copilot surface can see
"Can Copilot see multiple repos" has a different answer in the editor, on github.com, and in the cloud agent. Capabilities in this space move fast, so treat the table as checked against GitHub's own documentation on 27 July 2026.
| Surface | Multi-repo? | How it reaches | Where it stops |
|---|---|---|---|
| Copilot Chat in VS Code | Usually — multi-root workspace | A .code-workspace file listing several repository folders opens them in one window, and #codebase searches the workspace. VS Code documents the semantic index as covering it — "GitHub indexes the GitHub repositories in your workspace", plural — but never documents multi-root behaviour explicitly, and carries an open report that the semantic index does not build for multi-root workspaces (microsoft/vscode#313181, open since April 2026). Treat it as usually-works rather than guaranteed. | Somebody chose the folders list, from memory. The workspace is searched again every session, and grep cost grows with every folder added. |
| Copilot Chat on github.com | One repo — unless you attach a Space | Chat on github.com is scoped to the repository you opened it from. A Copilot Space is the supported way to widen it. | Without a Space, the repo you are looking at is the whole context. |
| Copilot Spaces | Yes — natively multi-repo | A Space holds "repositories, code, pull requests, issues, free-text content like transcripts or notes, images, and file uploads". GitHub-based sources are "automatically updated as they change". Any Copilot licence, including Copilot Free, can create one. | The Space holds exactly the repositories you decided to add. Curation is the whole job, and nothing tells you the set went stale. |
| Copilot cloud agent | No — one repo per task | GitHub is blunt about it: Copilot "cannot make changes across multiple repositories in one run", works "on one branch at a time", and "can open exactly one pull request to address each task it is assigned". | You can widen what it reads with an MCP server in its environment. You cannot widen what it changes. |
| Copilot CLI | Yes — trusted directories | Two documented routes. Launch copilot from a parent directory holding several repo folders and, once you confirm you trust the files "in, and below" it, GitHub says the CLI can "access and work across all child repositories simultaneously". Or start inside one repo and widen with /add-dir <path>, checking the result with /list-dirs. | Read "access" literally: GitHub defines trusted directories as controlling "where Copilot CLI can read, modify, and execute files". It is a recursive permission grant, not a semantic index — the CLI greps what it is allowed to touch and builds no cross-repo graph. Reach is not context parity either: github/copilot-cli#2011 reports instruction, skill and MCP discovery still resolving against a single directory, so each child repo's own copilot-instructions.md does not all load at once. |
| Copilot code review | No — the PR's own repo | GitHub describes its "full project context gathering" as analysing "your entire repository" — singular. Since June 2026 a repository-level MCP server can widen it, in public preview, sharing its configuration with the cloud agent. | The default GitHub MCP server "connects to GitHub with a specially scoped token that only has read-only access to the current repository"; going wider means minting a personal access token with broader scope. And you do not control invocation — the docs say skills and MCP servers are used only "when they are relevant to the review", so the model decides. |
| JetBrains IDEs | Project-wide, not repo-wide | @project is the JetBrains counterpart to @workspace. GitHub tells JetBrains users to "Use the @project chat participant" for questions about their project, but no maintained doc defines how much of it that reads. Separately, the Copilot CLI agent has run inside JetBrains in public preview since May 2026. | Its ceiling is the project open in the IDE, which is normally one repository — so it is not a view of your org. The launch-era claim that it reads "your entire project's codebase" has not been repeated in a maintained doc since February 2025; in practice it retrieves from an index and answers from the snippets it pulls back. |
| Visual Studio | One solution | Microsoft names the boundary after its own project model: @workspace "refer[s] to the solution active in the IDE for context". Copilot Enterprise users can add @github "to include context from their entire repository". | The label differs, the ceiling does not. Microsoft documents the search index as built per repository, so solution or repo, somebody still chose the project list by hand. |
Sources: GitHub's documentation on Copilot Spaces and the Copilot cloud agent.
Three ways to set it up
All three ship today. Which one you want is decided by the Copilot surface you actually live in, not by which is most capable in the abstract.
A multi-root workspace in VS Code
The cheapest path and the one most teams should try first. List the repository folders in a .code-workspace file, pair it with per-repo .github/copilot-instructions.md custom instructions, and both sides of a contract are in the window at once. At two to five tightly coupled repos, with someone keeping the instructions current, this works and it costs an afternoon.
A Copilot Space
The native option, and the one teams miss because it lives on github.com rather than in the editor. Assemble a curated context set spanning whole repositories, specific files, pull requests, issues and notes, attach custom instructions, share it with your organisation, and the GitHub-based sources stay synced as the code changes. Zero infrastructure, and the only multi-repo Copilot surface that is curated rather than merely permitted — Copilot CLI's trusted directories reach further, but they grant filesystem access rather than assemble a context set.
MCP in the cloud agent's environment
The only way to get cross-repo awareness into the autonomous path. Configure an MCP server through the agent's copilot-setup-steps.yml, typically the GitHub MCP server, with a fine-grained personal access token stored as an Actions secret and scoped read-only to the sibling repositories it needs. The most operational surface of the three: a token to mint, rotate and audit, and a security review about why an autonomous agent holds credentials beyond the repo it is changing.
The step-by-step version of all three, including the workspace file, the
copilot-setup-steps.yml wiring, and what each approach costs to keep
running, is in
how to give GitHub Copilot cross-repo context today.
Does any of this survive to tomorrow?
This is the question people actually arrive with, usually phrased as some version of "can Copilot remember the other repo from yesterday". Three different things get conflated in it, and they have three different answers.
The repository list persists. A
checked-in .code-workspace file is a durable artifact, and so is a Space's
source list — its GitHub-based sources stay synced as the code changes. Whatever set you
assembled, you get back.
The conversation partly persists.
Copilot CLI sessions can be reopened: /resume shows a picker of previous
sessions and continues one with the saved context. Prefer it to
copilot --continue if you work across several repos — since v1.0.35 that
shortcut prefers sessions from the current working directory rather than the one you
closed last, so running it from a different repo will not give you the session you
expect. In VS Code, a chat session is scoped to the workspace it was created in. Whether
it syncs off your machine depends on who pays for your Copilot: individual plans sync to
your GitHub account by default, while on Copilot Business and Enterprise an
administrator must enable the policy first, and an org that has never touched it stores
sessions locally only.
The index does not persist as understanding. It is searched again each session, and the grep cost grows with every folder you added.
So the honest answer is that you get back the folders you chose, and sometimes the transcript. What none of these stores is the relationship between the repositories — which one consumes the artifact the other publishes. A transcript is a record of what was said about the repos, not a model of how they connect, and reloading it tomorrow does not make yesterday's repository list any less hand-picked. That is a different kind of object, and it is the subject of the next two sections.
Which repositories?
Look at what the three approaches have in common. A .code-workspace file
with a folders list. A Space with a sources list. A token scoped to a repository list.
Every one of them answers "how do I put more repositories in front of Copilot", and
every one quietly delegates the harder question back to you: which repositories.
That list is a hand-maintained model of what depends on what, and maintaining it has a name on this blog, because platform teams have been running the same experiment for years with service catalogs. It is the catalog maintenance trap. The list is accurate the day it is written, it drifts the moment the system changes, and nothing tells you it drifted. A workspace missing the repo that consumes your contract does not error. It gives the agent a confident, complete-looking view of an incomplete world, which is exactly where a wrong map beats no map for damage done.
Nothing else in the GitHub stack answers it either. Renovate and Dependabot read your manifests every day, one repository at a time, and then forget what they saw — asked directly about cross-repository detection, a Renovate maintainer's answer this May was that "Renovate only operates on a per-repository basis", with no plans to change.
But for most of the edges that matter, the answer is already written down. A
package.json dependency on a contracts package. A go.mod
require. Terraform source blocks, Dockerfile FROM lines, Helm
chart dependencies, CI includes and reusable workflow uses:
references. Those edges are declared, not inferred, and they are sitting in your org's
manifests unassembled. Assembling them is
cross-repo dependency mapping.
Derive the list instead of maintaining it
A queryable cross-repo dependency graph does not replace the three approaches above. It feeds them. Generate the folders array, the Space's source list, and the agent token's repo scope from a dependents query instead of from memory, and when the graph changes the lists change with it:
$ curl api.riftmap.dev/api/v1/repositories/{id}/impact \
-H "X-API-Key: $RIFTMAP_KEY"
{ "affected": [
{ "repo": "acme/web-app", "depth": 1 },
{ "repo": "acme/batch-jobs", "depth": 2 }
], "total_affected": 9 }The same call works as a tool during the task. In agent mode Copilot can call out to tools, so a planning step can ask who depends on the thing it is about to touch before the first edit. Meta's April 2026 write-up on their tribal knowledge engine puts the economics at roughly 200 tokens for a graph lookup against roughly 6,000 for answering the same question by exploration, a 30-times reduction. Riftmap for AI coding agents covers the endpoints and the staleness contract that stops an agent trusting a graph older than the last push.
You do not need this product to adopt the pattern. Mabl built their own coordination graph by hand and runs agents across 100-plus repositories on top of it. A parsed, queryable graph underneath, and Copilot consuming it, is the architecture either way. Every one of these approaches ends in a list of repositories somebody has to get right. You can maintain that list, or you can derive it.
Common questions
01 Can GitHub Copilot work across multiple repositories?
Partly, and it depends on which Copilot surface you are using. Copilot Chat in VS Code reaches across repositories when you open them together in a multi-root workspace. Copilot Spaces is natively multi-repo: a Space can hold whole repositories alongside files, issues and pull requests, and its GitHub sources stay synced. The Copilot cloud agent cannot — GitHub documents that it cannot make changes across multiple repositories in one run, works on one branch at a time, and opens exactly one pull request per task. All three approaches end in a list of repositories somebody chose by hand.
02 Can Copilot read another repository, or reference a second repo for context?
Yes, through one of four mechanisms, depending on the surface. In VS Code, add the second repository as a folder in a multi-root workspace and Copilot indexes it alongside the first. On github.com, add it as a source in a Copilot Space. In Copilot CLI, launch from a parent directory holding both repos or widen access with /add-dir. For the cloud agent, configure an MCP server in its environment with a fine-grained token scoped read-only to the sibling repository. The full setup for all three is written up separately. What none of these does is tell you which second repository you should have added.
03 How do I use Copilot across two repos in VS Code at once?
Create a multi-root workspace. A .code-workspace file lists several repository folders that open together in one window, Copilot Chat indexes every folder in the workspace, and #codebase searches all of them. For the common case of a web app and the service it consumes, this puts both sides of the contract in the window, so "does the frontend call anything I just renamed" becomes an answerable question. The refinement worth copying is a dedicated context-only repository added as a fourth folder, holding shared Copilot instructions that describe the architecture and point at each repo's own conventions.
04 Can the Copilot cloud agent work across repositories?
Not for changes. GitHub's documentation states that Copilot cannot make changes across multiple repositories in one run, works on one branch at a time, and can open exactly one pull request to address each task it is assigned. You can widen what it reads by configuring an MCP server in the environment defined by its copilot-setup-steps.yml workflow, typically the GitHub MCP server with a fine-grained personal access token stored as an Actions secret. That gives the agent read access to sibling repositories mid-task. It does not let one task change two repositories.
05 What is the best way to share Copilot context across repositories?
For a team that lives on github.com, an organisation-owned Copilot Space is the most durable option: it can be shared with other organisation members at admin, editor or viewer level, and its GitHub-based sources update automatically as the code changes, so it does not need re-uploading. For editor-bound work, a checked-in .code-workspace file plus per-repo .github/copilot-instructions.md files gives every engineer the same folder set and the same conventions. Both still depend on the repository list being right, which is the part that decays.
06 Can Copilot CLI work across two repositories at once?
Yes, and it is currently the most direct route. GitHub documents two ways: launch copilot from a parent directory containing several repository folders and confirm you trust the files in and below it, after which GitHub says the CLI can access and work across all child repositories simultaneously; or start inside one repository and widen access with /add-dir, checking what is allowed with /list-dirs. Read "access" literally — GitHub defines trusted directories as controlling where Copilot CLI can read, modify and execute files, so it is a recursive permission grant rather than a semantic index. The CLI greps what it is allowed to touch. It does not build a dependency graph across those repositories, and it does not tell you which sibling repository you should have added.
07 Does Copilot remember context from another repository between sessions?
Three different things get conflated here, and only two of them persist. The repository list persists: a .code-workspace file and a Copilot Space's source list are both durable artifacts, and a Space's GitHub-based sources stay synced as the code changes. The conversation partly persists: Copilot CLI sessions can be reopened with /resume, which continues a previous session with the saved context, and VS Code scopes a chat session to the workspace it was created in. The index does not persist as understanding — it is searched again each session. What none of them stores is the relationship between the repositories. You get back the folders you chose and, sometimes, the transcript; you never get back a model of which repository consumes which artifact, because nothing built one.
08 Can Copilot code review see across repositories?
Not by default. GitHub describes Copilot code review's full project context gathering as analysing your entire repository — singular — meaning the repository containing the pull request. There is one documented way past that boundary and it is not automatic: since June 2026, in public preview, code review can use repository-level MCP servers, sharing that configuration with the Copilot cloud agent. The default GitHub MCP server connects with a token scoped read-only to the current repository, so reaching further means minting a personal access token with wider access and accepting the review that comes with it. You also do not control when it is used: GitHub says repository-level skills and MCP servers are consulted only when they are relevant to the review.
09 Does Copilot know which repositories depend on the one I am changing?
No. That is a different question from context, and no Copilot surface answers it. A workspace, a Space and a scoped token are all ways of putting more repositories in front of Copilot; none of them derives which repositories consume the artifact you are about to change. Those edges are declared in manifests across the org — Dockerfile FROM lines, Terraform source blocks, go.mod requires, Helm chart dependencies, CI includes — and they only become an answer once something parses them into a graph you can query. That query is what turns the hand-maintained repository list into a derived one.
Keep reading
See the graph Copilot is missing
Riftmap is a change impact engine for multi-repo systems. It scans a GitHub or GitLab organisation with one read-only token, auto-discovers every cross-repo dependency from the actual source files across 12 ecosystems, and serves the result two ways: an interactive blast-radius view for engineers, and an HTTP API for Copilot and other agents to query before they change anything. No per-repo configuration, no YAML to maintain. The Prometheus graph below is live and needs no login.