How to give GitHub Copilot cross-repo context today

如何在今天为 GitHub Copilot 提供跨仓库上下文

In March 2026, someone filed a feature request on GitHub Community that I have thought about more than any product announcement from that month. The setup is two repositories. A web app and an orders-service it consumes. The web app calls the service’s endpoints, depends on its DTOs, and has to stay aligned with every route rename, payload change, and validation rule. 2026 年 3 月，有人在 GitHub 社区提交了一个功能请求，我对它的思考比当月任何产品发布都要多。场景是两个仓库：一个 Web 应用及其调用的订单服务（orders-service）。Web 应用调用该服务的端点，依赖其数据传输对象（DTOs），并且必须与每一次路由重命名、负载变更和验证规则保持同步。

The request walks through what Copilot cannot do across that boundary: it cannot reason about contracts defined in the other repo, cannot detect when the frontend calls an endpoint that no longer exists, cannot coordinate one change across both sides. It ends with two questions. Is this on the roadmap, and are there recommended best practices to approximate this behaviour today? GitHub has not answered. 该请求详细说明了 Copilot 在跨仓库边界时无法完成的工作：它无法推理另一个仓库中定义的契约，无法检测前端何时调用了已不存在的端点，也无法协调跨两端的变更。请求最后提出了两个问题：这是否在路线图中？目前是否有推荐的最佳实践来近似实现这种行为？GitHub 尚未给出答复。

I eventually left a reply in the thread myself, because the second question deserved one, and this post is the long version of that reply. The honest answer is more useful than “wait for the roadmap”. As of June 2026 there are three working ways to give GitHub Copilot context across repositories. All three are real, all three ship today, and all three have a ceiling that is worth knowing about before you invest in one. Underneath all three sits the same unanswered question, and that question is the part I actually want to get to. 我最终自己在该帖中留了言，因为第二个问题值得回答，而这篇文章就是那条回复的详细版本。诚实的回答比“等待路线图”更有用。截至 2026 年 6 月，有三种有效的方法可以为 GitHub Copilot 提供跨仓库上下文。这三种方法都是真实的，目前均已上线，且在投入使用前，了解它们各自的局限性非常重要。这三种方法背后都隐藏着同一个未解的问题，而这正是我真正想探讨的部分。

What Copilot can see today, precisely

Copilot 今天究竟能看到什么

It is worth being precise here, because the answer is different for each Copilot surface, and it changes fast enough that this paragraph carries a date. Copilot Chat in VS Code sees the workspace you have open. One folder open means one repo’s worth of context. Copilot Chat on github.com is scoped to a single repository, or to a Space, which we will get to. And the Copilot cloud agent, the one you hand an issue and get a pull request back from, runs in its own environment scoped to the single repository where the task was opened, holding a repository-scoped GITHUB_TOKEN that cannot read its siblings. 在这里有必要精确说明，因为每个 Copilot 界面（surface）的答案都不同，且变化速度很快，因此本段标注了日期。VS Code 中的 Copilot Chat 可以看到你打开的工作区。打开一个文件夹意味着只有一个仓库的上下文。github.com 上的 Copilot Chat 仅限于单个仓库，或者我们稍后会提到的“空间”（Space）。而 Copilot 云代理（即你提交一个 Issue 并获得 Pull Request 的那个工具）运行在它自己的环境中，仅限于任务开启的单个仓库，并持有无法读取同级仓库的仓库级 GITHUB_TOKEN。

None of this is an oversight. It is a permissions model doing its job. Which is why every working approach to cross-repo context is a way of routing around that model deliberately: widen the workspace, curate a context set, or hand the agent extra credentials. Those are the three approaches, in that order. 这些都不是疏忽，而是权限模型在发挥作用。正因如此，每一种实现跨仓库上下文的有效方法，本质上都是在刻意绕过该模型：扩大工作区、策划上下文集，或为代理提供额外凭据。这就是三种方法，按此顺序排列。

Approach 1: a multi-root workspace in VS Code

方法 1：VS Code 中的多根工作区（Multi-root workspace）

The cheapest path, and the one most teams should try first. VS Code supports multi-root workspaces: a .code-workspace file listing several repository folders that open together in one window. 这是成本最低的路径，也是大多数团队应该首先尝试的方法。VS Code 支持多根工作区：一个 .code-workspace 文件，列出在同一个窗口中一起打开的多个仓库文件夹。

{
  "folders": [
    { "path": "web-app" },
    { "path": "orders-service" },
    { "path": "platform-context" }
  ]
}

Copilot Chat indexes across every folder in the workspace, and #codebase searches all of them. For the web-app and orders-service case this is genuinely transformative: both sides of the contract are in the window, so “does the frontend call anything I just renamed” becomes an answerable question. Copilot Chat 会索引工作区中的每个文件夹，#codebase 也会搜索所有这些文件夹。对于 Web 应用和订单服务的情况，这确实具有变革性：契约的两端都在窗口中，因此“前端是否调用了我刚刚重命名的内容”变成了一个可以回答的问题。

The pattern has grown a refinement that is worth copying. Several teams now pair the workspace with repository custom instructions, a .github/copilot-instructions.md per repo, and the more advanced version adds a dedicated context-only repository to the workspace. Arinco published a detailed writeup of running this across a 15-plus-repo platform this week: a repo containing nothing but Copilot customisation files, added as a workspace folder, whose shared instructions file acts as a routing table describing the architecture and pointing at each repo’s own conventions. 这种模式已经发展出一种值得借鉴的改进方案。现在，一些团队将工作区与仓库自定义指令（每个仓库一个 .github/copilot-instructions.md）结合使用，更高级的版本则会在工作区中添加一个专门用于存放上下文的仓库。Arinco 本周发布了一篇详细文章，介绍了如何在拥有 15 个以上仓库的平台上运行此方案：一个仅包含 Copilot 自定义文件的仓库被添加为工作区文件夹，其共享指令文件充当路由表，描述架构并指向每个仓库自身的约定。

That is the strongest version of the approach, so let me be fair to it before drawing the line. At two to five tightly coupled repos, with someone who cares keeping the instructions current, this works, and it costs an afternoon. It stops in three ways, and they compound. 这是该方法最强大的版本，所以在划定界限之前，我必须公正地评价它。在两到五个紧密耦合的仓库中，如果有专人负责保持指令更新，这种方法是有效的，且只需花费一个下午的时间。但它在三个方面会遇到瓶颈，且这些问题会叠加。

First, the workspace does not load itself into the model’s context. The agent searches and greps it, every session, and that cost is paid again every session. Meta’s published numbers put a graph lookup for “what depends on X” at roughly 200 tokens against roughly 6,000 for answering the same question by exploration, a 30x difference I went through in detail in the virtual monorepo post. Grep over a workspace is O(N) in workspace size, and the workspace only ever grows. 首先，工作区不会自动加载到模型的上下文中。代理在每次会话中都会对其进行搜索和 grep 操作，且每次会话都要付出同样的成本。Meta 公布的数据显示，针对“什么依赖于 X”的图查询大约需要 200 个 token，而通过探索回答同样的问题则需要约 6,000 个 token，这有 30 倍的差距，我在关于虚拟单体仓库（virtual monorepo）的文章中详细讨论过。对工作区进行 grep 的复杂度是 O(N)，且工作区只会越来越大。

Second, the instructions file decays. It is a hand-written map of how the system fits together, and the system keeps moving after the map is written. The research on hand-written context files is sobering, marginal gains at meaningfully higher inference cost, and Meta’s engineering team named the underlying problem in one line: “context that decays is worse than no context”. A confident agent navigating by a stale map does not feel stale. It feels fast, right up until the change lands. 其次，指令文件会失效。它是一张关于系统如何组合的手绘地图，而系统在地图绘制后会不断演进。关于手绘上下文文件的研究结果令人清醒：在显著增加推理成本的情况下，收益却微乎其微。Meta 工程团队用一句话指出了根本问题：“失效的上下文比没有上下文更糟糕”。一个依靠过时地图导航的自信代理，在变更落地之前，并不会让你感觉到它已经过时，反而会让你觉得它很快。

Third, somebody chose which folders go in that .code-workspace file, and they chose from memory. Hold that thought. 第三，有人选择了哪些文件夹放入 .code-workspace 文件，而他们是凭记忆选择的。记住这一点。

Approach 2: Copilot Spaces

方法 2：Copilot Spaces

The native option, and the one I see teams miss because it lives on github.com rather than in the editor. Copilot Spaces let you assemble a curated context set, including entire repositories, plural, alongside specific files and folders, pull requests, issues, uploaded documents, and free-text notes, then chat with Copilot grounded in exactly that set. You can attach custom instructions, share the space with your organisation, and the GitHub-based sources stay synced as the code changes. Any Copilot licence can use it. 这是原生选项，也是我看到许多团队错过的功能，因为它位于 github.com 而非编辑器中。Copilot Spaces 允许你组装一个精心策划的上下文集，包括多个完整的仓库，以及特定的文件和文件夹、Pull Request、Issue、上传的文档和自由文本笔记，然后基于该集合与 Copilot 对话。你可以附加自定义指令，与组织共享空间，且基于 GitHub 的源会随着代码变更保持同步。任何 Copilot 许可证均可使用。

Credit where due: this is zero infrastructure, it is the only genuinely multi-repo Copilot surface GitHub ships today, and for a team that lives on github.com it is the lowest-friction answer on this list. A space holding web-app, orders-service, and the API contract files is a real improvement for onboarding questions, contract questions, and “explain how these fit together” questions. The ceiling is in how it retrieves. When you attach a whole repository, Copilot searches within it for relevant content rather than loading it, and GitHub’s own guidance is to curate the specific files that matter because… 必须给予肯定：这无需任何基础设施，是 GitHub 目前提供的唯一真正支持多仓库的 Copilot 界面。对于常驻 github.com 的团队来说，这是此列表中阻力最小的方案。一个包含 web-app、orders-service 和 API 契约文件的空间，对于入职引导问题、契约问题以及“解释它们是如何组合在一起的”这类问题，确实有显著改进。其局限性在于检索方式。当你附加整个仓库时，Copilot 会在其中搜索相关内容而不是直接加载它，而 GitHub 官方的建议是策划出重要的特定文件，因为……